As part of the Agile/Jazz event In Milwaukee on the 29th I'll be giving a talk about the realities of agile software development. The URL for the event is http://www.iconatg.com/lp/events/jazz/jazz_milwaukee.html and I hope to see you there.
- Scott[Read More]
Agility@Scale: Strategies for Scaling Agile Software Development
Free Agile/Jazz Seminar in Milwaukee on January 29, 2009 |
Criteria for a Disciplined Agile Team
ScottAmbler
Tags: 
disciplined-agile-deliver...
spi
agileadopt
governance
criteria
5 Comments
14,432 Views
Although it might not be obvious, and important success factor in adopting agile techniques is to be able to determine whether a team is agile or not. The challenge that many organizations face is that many teams will claim to be agile, yet management, who often has little or no experience with agile approaches, cannot tell which claims are true and which are over zealous (I'm being polite). The following are the criteria that I suggest you look for in a disciplined agile team:1. Produce working software on a regular basis. This is one of the 12 principles behind the Agile Manifesto, and in my experience is a critical differentiator between the teams that are agile and those that are merely claiming it. Ideally the team should produce potentially shippable software each iteration. That doesn't mean that they'll deploy the system into production, or the marketplace, each iteration but they could if required to do so. Typically the team will deploy into a pre-production testing environment or a demo enviroment at the end of each iteration (or more often for that matter).2. Do continuous regression testing, and better yet take a Test-Driven Development (TDD) approach. Agile developers test their work to the best of their ability, minimally doing developer regression testing via a continuous integration (CI) strategy and better yet do developer-level TDD. This approach enables development teams to find defects early, thereby reducing the average cost of addressing the defects, it also helps them to deliver higher quality code and to move forward safely when adding or changing functionality.3. Work closely with their stakeholders, ideally on a daily basis. A common practice of agile teams is to have an on-site customer or product owner who prioritizes requirements and provides information on a timely manner to the team. Disciplined agile teams take it one step further and follow the practice active stakeholder participation where the stakeholders get actively involved with modeling and sometimes even development.4. Are self-organizing within a governance framework. Agile teams are self-organizing, which means that the people doing the work determines how the work will be done, they're not told by a manager who may not even be directly involved with the work how it will be done. In other words the team does its own planning, including scheduling and estimation. Disciplined agile teams are self governing within an effective governance framework.5. Regularly reflect on how they work together and then act to improve on their findings. Most agile teams hold a short meeting at the end of each iteration to reflect upon how well things are working and how they could potentially improve the way that they are working together. Sometimes this is done in a more formalized manner in the form of a retrospective, but often it's done informally. The team then acts on one or more of their suggested improvements the next iteration. Disciplined agile teams take this one step further and measure their software process improvement (SPI) progress over time: the act of taking these measures, perhaps via a product such as Rational Self Check, helps to keep the team on track in their SPI efforts.
I have yet to discover an ad-hoc development team which met all five criteria, and most of them rarely meet two or three. Further reading:
[Read More] |
Rational Agile Page
And now for some blatant advertising. ;-)
I just wanted to point out our agile development page to you as it contains links to a lot of interesting agile resources produced by the folks here at Rational. There's links to white paper, recorded web casts, and Rational's Agility@Scale poster. Short story is that the page is worth checking out. - Scott[Read More] |
Bureaucracy Isn't Discipline
ScottAmbler
Tags: 
culture
disciplined-agile-deliver...
antipattern
agileadopt
repeatability
7 Comments
16,652 Views
Again and again I've seen IT organizations suffering from what I call the "Bureaucracy is Discipline" antipattern. For example, filling out forms and reviewing documents are both bureaucratic activities, neither of which require significant skill nor discipline to accomplish. However, agile practices such as developing potentially shippable software every iteration is easy to say but requires great discipline to accomplish. Respecting the decisions of your stakeholders, particularly those pertaining to requirements prioritization, is easy to talk about but proves to require great discipline in practice (particularly when you don't agree with a decision). It's easy to talk about taking a test-driven approach to development, but in practice it requires significant skill and discipline to actually do.
A "process smell" which indicates that your organization is suffering from this antipattern is a focus on following repeatable processes instead of focusing on repeatable results. An example of repeatable processes is following the same route to work every day regardless of driving conditions. An example of repeatable results is getting to work on time every day, but being willing to change your route as required, bicycling into work instead of driving, taking public transit, and so on. Nobody really cares how you get to work each day (the process), what they really care about is that you got to work on time (the result). Sadly, we've been told for decades now that repeatable processes are critical to our success in IT, yet when you step back and think about that's really a reflection of a bureaucratic approach. On the other hand, a focus on repeatable results is a reflection of a more disciplined approach. Interestingly, the DDJ 2008 Process Framework survey found that given the choice that people would much rather have repeatable results over repeatable processes when it comes to IT. Mistaking bureaucracy for discipline, or rigour if you prefer that term, is a reflection of the cultural damage that has occurred over the years in IT organizations as the result of traditional philosophies and techniques. Unfortunately, this mistaken belief is a significant inhibitor to software process improvement (SPI) efforts, in particular agile adoption efforts, which must be addressed if you're to be successful. Overcoming this challenge will require a significant cultural shift in some organizations, and many people (particularly the bureaucrats) will find this uncomfortable. Further reading:
I'd like to leave you with this parting thought: Bureaucracy is bureaucracy and discipline is discipline, please don't confuse the two.[Read More] |
Agile Adoption Antipattern: We're Special
An inhibitor that I run into again and again within organizations that are still in the process of adopting agile development techniques is something that I call the "We're Special" anti-pattern. The people involved believe that their situation is special, that some unique factor in their environment makes it all but impossible to adopt agile techniques, and therefore they need to continue to work in the manner that they've always worked, regardless of the obvious inefficiencies of doing so.
An organization suffers from this agile adoption anti-pattern when they start giving domain-based or technology-based excuses for why they can't become more agile. For example, I've heard bank employees claim that "Agile works fine for building web sites, but we're building financial systems therefore agile won't work for us", telecom employees claim "Agile works fine for building financial systems, but we're building embedded systems therefore agile won't work for us", and government employees claim "Agile works fine for embedded systems, but we're building web sites therefore agile won't work for us." Needless to say I often struggle to not roll my eyes. The reality is that the business domain that you're working in doesn't dictate your ability to adopt agile strategies. I've seen very successful agile projects in banks, insurance companies, manufacturing companies, retail companies, pharmacueticals (yes, life critical applications), telecoms, and government agencies. I've also met people working in those domains claim that they're special because of the inherent challenges of the domain. Similarly, technology isn't an issue. I've seen project teams that were successful at applying agile approaches using Java, VB, COBOL, C, Linux, Windows, System Z, on PCs, and so on. Granted, some technology platforms suffer from a plethora of "agile tooling", PL/1 comes to mind and I'm sure that there's a few more niche platforms where this is the case, but with a little online searching it's often possible to find good open source tools out there (or what's stopping you from starting such a project?). The primary issues around agile adoption are cultural in nature. Can you become more flexible in your thinking? Can you become more disciplined (agile requires greater levels of discipline than traditional approaches)? Can you build a collaborative environment with your business stakeholders? Can you move away from bureaucratic processes to ones which focus on adding real value? Can you invest in your IT staff to give them modern development skills required for test-driven development (TDD), continuous integration, and agile database techniques (to name a few)? Addressing the "people issues", the cultural issues, is the hard part of moving towards agile. If you're looking for valid excuses for why your organization can't move to agile, here's some valid adoption inhibitors that I see in organizations all the time:
The above list is just the tip of the iceberg. The point is that the real problems that you face are cultural in nature, not domain-based nor technology-based. It is possible to overcome these inhibitors to success, but you need to understand that you're suffering from them, what the implications are, and how to overcome them. This is one of the facets of the Health Assessment portion of our new Measured Capability Improvement Framework (MCIF) service, the goal of which is to help organizations improve their internal IT processes. Although MCIF isn't specifically about becoming more agile, the reality is that there are a lot of great agile practices out there, and some of them are good options for your organization. Assuming of course you get over your misconception that you're special for some reason and instead accept the need that you've got some hard slogging ahead of you to improve your IT game. Further reading:
[Read More] |
Acceleration: An Agile Productivity Measure
A common goal of IT governance is to determine the productivity of various techniques, tools, and people as part of the overall effort to improve said productivity. If you can easily measure productivity you can easily identify what is working for you in given situations, or what is not working for you, and adjust accordingly. A common question that customers ask me is how do you measure productivity on agile teams. Although you could use traditional strategies such as function point (FP) counting, or another similar strategy, this can require a lot of effort in practice. Remember that we don't only want to measure productivity, we want to do so easily. Ideally it would be nice to do so using information already being generated by the team and therefore we won't add any additional bureaucratic overhead.
A common metric captured by agile teams is their velocity. Velocity is an agile measure of how much work a team can do during a given iteration. At the beginning of an iteration a team will estimate the work that they're about to do in terms of points. At the beginning of a project the team will formulate a point system, which typically takes a few iterations to stabilize, so that they can consistently estimate the work each iteration. Although the point system is arbitrary, my team might estimate that a given work item is two points worth of effort whereas your team might think that it's seven points of effort, the important thing is that it's consistent. So if there is another work item requiring similar effort, my team should estimate that it's two points and your team seven points. With a consistent point system in place, each team can accurately estimate the amount of work that they can do in the current iteration by assuming that they can achieve the same amount of work as last iteration (an XP concept called "yesterday's weather"). So, if my team delivered 27 points of functionality last iteration we would reasonably assume that we can do the same this iteration. So, is it possible to use velocity as a measure of productivity? The answer is not directly. For example, we have two teams, A and B, each of 5 people and each working on a web site and each having two-week long iterations. Team A reports a velocity of 17 points for their current iteration and team B a velocity of 51 points. They're both comprised of 5 people, therefore team B must be three times (51/17) as productive as team A. No! You can't compare the velocity of the two teams because they're measuring in different units. Team A is reporting in their points and B in their points, so you can't compare them directly, The traditional strategy would be to ask the teams to use the same unit of points, which might be a viable strategy with two teams although likely not if you have twenty agile teams and particularly not if you have two hundred teams. Regardless of the number of teams that you have it would minimally require some coordination to normalize the units and perhaps even some training and development and support of velocity calculation guidelines. Sounds like unnecessary bureaucracy that I would prefer to avoid. Worse yet, so-called "consistent" measurements such as FPs are anything but because there's always some sort of fudge factor involved in the process which will vary by individual estimator. An easier solution exists. Instead of comparing velocities you instead calculate the acceleration of each team. For example, consider the reported velocities of each team below. Team A's velocity is increasing over time whereas team B's velocity is trending downwards. All things being equal, you can assume that team A's productivity is increasing whereas B's is decreasing. Of course it's not wise to manage simply by the numbers, so instead of assuming what is going on I would rather go and talk with the people on the two teams. Doing so I might find out that team A has adopted quality-oriented practices such as continuous integration and static code analysis which team B has not, indicating that I might want to help team B adopt these practices and hopefully increase their productivity. Team A: 17 18 17 18 19 20 21 22 22 ...Team B: 51 49 50 47 48 45 44 44 41 ... There are several advantages to using acceleration as an indicator of productivity over traditional techniques such as FP counting:1. It's easy to calculate. For example, the acceleration of team A from iteration 1 to iteration 6 is (20-17)/17 = 0.176 whereas for team B it is (45-51)/51 = -.118. Of course, you don't need to calculate the acceleration over such a long period of time, you could do it iteration by iteration, although I find that doing it over several iterations gives a more accurate value. You'll need to experiment to determine what works for you.2. It is inexpensive. Acceleration is based on information already being collected by the team, their velocity, so there is no extra work to be done by the team. 3. It is unlikely to be gamed. Teams aren't motivated to fake their velocity because it provides them with important information required to manage themselves effectively. 4. It is easy to automate. For example, Rational Team Concert (RTC) calculates velocity automatically from its work item list (an extension of Scrum's product backlog) and does trend reporting via it's web-based project reporting functionality, providing a visual representation of the team's acceleration (or deceleration as the case may be).5. It offers the opportunity for more effective governance. This approach reflects three of the practices of Lean Development Governance: Simple and Relevant Metrics, Continuous Project Monitoring, and Integrated Lifecycle Environment.6. You can easily adjust for changing team size. If the size of a team varies over time, and it will, this metric falls apart the way that I've described it. To address this issue you need to normalize it by dividing by the number of people on the team to get the average acceleration per team member.7. You can easily monetize this metric. By knowing the acceleration of the project team and knowing how much they're spending each iteration, you can estimate the amount of money you're saving through process improvement. For example, if you're spending $100,000 per iteration and your acceleration is 2%, your cost savings is $2,000 per iteration. Of course, nothing is perfect, and there are a few potential disadvantages:1. It is an indirect measure of productivity. Truth be told velocity really is a productivity measure, it's just that because it's measured in different units it's difficult to compare between teams. Acceleration is merely an indicator of the change in productivity.2. You actually need to measure what you're interested in. When you step back and think about it, you're not really interested in measuring your productivity, regardless of what the metrics wonks have been telling you the past few decades. In this case what you really want to know is your change in productivity because your real goal is to improve your productivity over time, which is what acceleration actually measures.3. Management must be flexible. For this to be acceptable senior management must be willing to think outside the "traditional metrics box". Using a non-standard, simple metric to calculate productivity? Preposterous! Directly measuring what you're truly interested in instead of calculating trends over long periods of time? Doubly preposterous!4. Your existing measurement program may be questioned. Once management learns how easy it can be to obtain metrics which enables them to truly govern software development projects they may begin to question the investment that they've made in the past in overly complex and expensive metrics schemes. This can be dangerous for the metrics professionals in your organization, particularly if your metrics group doesn't have valid measurements around the value of their own work. Ummmmm....5. The terminology sounds scientific. Terms such as velocity and acceleration can motivate some of us to start believing that we understand the "laws of IT physics", something which I doubt very highly that as an industry we understand. All it would take is for someone to start throwing around terms like "standard theory" and "unified model" and we'd really be in trouble. Wait a minute..... ;-) In summary, measuring the acceleration of development teams is an easy to collect, straightforward measure of team productivity. I hope that I've given you some food for thought, and would be eager to hear about your experiences applying this metric in practice. [Read More] |
Questioning Case Studies
I'm often asked by customers for case studies of successful agile adoptions or agile projects in general. This is definitely a valid request, and yes, such case studies exist. But I'm often concerned that the people making these requests don't appreciate the implications of what they're asking for. My concerns with case studies are:
Further reading:[Read More] |
Agility at Scale Poster Now Available
I'm happy to announce Rational's Agility at Scale poster which is currently available free of charge from the Rational poster order page.
Although I'm obviously biased as I was involved with its creation, the poster includes some really good information about how to scale agile software development practices effectively. It summarizes the scaling factors, such as large teams, distribution, regulatory compliance, application complexity, and so on that you should be concerned with. It also presents a full agile software development lifecycle that goes beyond the construction focused lifecycles of common "agile in the small" processes. It also summarizes the practices of lean development governance, giving you some insight into how to govern your IT environment more effectively. I think it's a pretty good poster that's worth checking out. It's free, so it's hard to argue with the price. Most importantly, it would look pretty good hanging on your office wall. [Read More] |
Large Agile Teams
A common misunderstanding about agile software development approaches are that they're only applicable to small, co-located teams. Yes, it's much easier to be successful with small teams, and with co-located teams, and as a result agilists being smart people prefer to work this way. After all, why take on extra risk when you don't need to do so? But, sometimes reality gets in the way and you find yourself in a situation where you need a large team, or you need to distribute your team (see previous blog postings for strategies for distributed agile development), and you would still like to be as agile as possible. The good news is that it's still possible to be agile with a large team, although you will need to go beyond some of the popular "agile in the small" strategies to succeed.
Here are some disciplined agile strategies to succeed at large-team agile:
Further reading:
|
Strategies for Distributed Agile Teams, Part 3
ScottAmbler
Tags: 
distributed
gdd
agility-at-scale
scaling-agile
geographic-distribution
sdcf
1 Comment
12,529 Views
I just wanted to round out my discussion about agile approaches to geographically distributed development (GDD) with a few important words of advice:1. Get some experience. Worry less about enterprise adoption and instead get started with a small project, or better yet a series of increasingly more complex projects. There will be learning experiences as you build a relationship with the offshore service provider. This advice is applicable whether you’re working with your own offshore division or with an independent service provider.2. Have a long-term staffing strategy. It may be great in the short term to have work done in a lower cost country, but how are you going to transfer the necessary skills to the maintenance and support team. Outsourcing that work is also an option, but it can be a risky one as you would need to build up expertise in “your” systems if you ever decide to insource that work again.3. Be concerned about intellectual property (IP). The rules are different around the world, and you may inadvertently be financing the creation of a new international competitor if you don’t have a clear division of ownership. And yes, this may mean that some components of your systems are still built internally by your own organization.4. Show off locally before you go global. GDD makes things harder to manage, so if you’re struggling to manage local teams you’re really going to struggle managing teams at a distance. Make sure you have local success first and are good at agile development in general. Furthermore, if your agile GDD projects run into trouble, don’t end your local agile adoption just because of difficulties with distributed projects.5. Let your offshore partners lead. The offshore partner likely has more experience than you at successful distributed development, and this is particularly true when you’re dealing with an established service provider.6. Do some reading. There’s a great IBM Redbook entitled “Global Development and Delivery in Practice: Experiences of the IBM Rational India Lab” which can be downloaded free of charge from http://www.redbooks.ibm.com/abstracts/sg247424.html7. Do some viewing. We recorded a Rational Chat a few months ago entitled "Being Agile in a Global Development Environment" which is posted at https://www14.software.ibm.com/webapp/iwm/web/reg/acceptSignup.do?lang=en_US&source=dw-c-wcsdpr&S_PKG=120607&S_TACT=105AGX23&S_CMP=TALKS&cp=UTF-8 . I also gave a keynote on Agile approaches to GDD at Software Development Practices 2007 held in Boston in the Autumn of 2007. The video can be downloaded free of charge from http://www.life20.net/video/scottambler.mov .[Read More]
Modified by ScottAmbler
|