Disciplined Agile

In Implementing Lean Software Development, Mary and Tom Poppendieck show how the seven principles of lean manufacturing can be applied to optimize the whole IT value stream. These principles are:

1. Eliminate waste. Lean thinking advocates regard any activity that does not directly add value to the finished product as waste. The three biggest sources of waste in software development are the addition of unrequired features, project churn and crossing organizational boundaries (particularly between stakeholders and development teams). To reduce waste it is critical that development teams be allowed to self organize and operate in a manner that reflects the work they’re trying to accomplish. Walker Royce argues that the primary benefit of modern iterative/agile techniques is the reduction of scrap and rework late in the lifecycle.
2. Build in quality.  Your process should not allow defects to occur in the first place, but when this isn’t possible you should work in such a way that you do a bit of work, validate it, fix any issues that you find, and then iterate.  Inspecting after the fact, and queuing up defects to be fixed at some time in the future, isn’t as effective.  Agile practices which build quality into your process include test driven development (TDD) and non-solo development practices such as pair programming and modeling with others.
3. Create knowledge.  Planning is useful, but learning is essential. You want to promote strategies, such as iterative development, that help teams discover what stakeholders really want and act on that knowledge. It’s also important for a team to regularly reflect on what they’re doing and then act to improve their approach.
4. Defer commitment.  It’s not necessary to start software development by defining a complete specification, and in fact that appears to be a questionable strategy at best. You can support the business effectively through flexible architectures that are change tolerant and by scheduling irreversible decisions to the last possible moment. Frequently, deferring commitment to the last most responsible moment requires the ability to closely couple end-to-end business scenarios to capabilities developed in multiple applications by multiple projects.
5. Deliver quickly.  It is possible to deliver high-quality systems quickly. By limiting the work of a team to its capacity, which is reflected by the team’s velocity (this is the number of “points” of functionality which a team delivers each iteration), you can establish a reliable and repeatable flow of work. An effective organization doesn’t demand teams do more than they are capable of, but instead asks them to self-organize and determine what they can accomplish. Constraining these teams to delivering potentially shippable solutions on a regular basis motivates them to stay focused on continuously adding value.
6. Respect people. The Poppendiecks also observe that sustainable advantage is gained from engaged, thinking people. The implication is that you need a lean approach to IT governance that focuses on motivating and enabling IT teams—not on controlling them.
7. Optimize the whole.  If you want to be effective at a solution you must look at the bigger picture. You need to understand the high-level business processes that individual projects support—processes that often cross multiple systems. You need to manage programs of interrelated systems so you can deliver a complete product to your stakeholders. Measurements should address how well you’re delivering business value, because that is the sole reason for your IT department.

A common question that customers ask us is how do you measure productivity on agile teams. 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. One way to do so is to look at acceleration, which is the change in velocity.

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. Velocity is typically measured using an arbitrary point system that is unique to a given team or program. For example, 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 all things being equal we can do the same this iteration.

It generally isn’t possible to use velocity as a measure of productivity. You can’t compare the velocity of the two teams because they’re measuring in different units. 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! Team A is reporting in their point system and B in their point system, so you can’t compare them directly. The traditional strategy, one that is also suggested in the Scaled Agile Framework (SAFe), would be to ask the teams to use the same unit of points.  This might be a viable strategy with a small number of teams although with five or more teams it would likely require more effort than it was worth.  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 consistent because there’s always some sort of fudge factor involved in the calculation process that will vary by individual estimator.

An easier solution exists. Instead of comparing velocities you instead calculate the acceleration of each team. Acceleration is the change in velocity over time. The exact formula for acceleration is:

(NewVelocity – InitialVelocity)/InitialVelocity

For example, consider the reported velocities of each team shown in the table 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. At the end of iteration 10, if we wanted to calculate the acceleration since the previous iteration (#9), it would be (23-22)/22= 4.5% for Team A and (40-41)/41 = -2.4% for Team B.  So Team A improved their productivity 4.5% during iteration 10 and Team decreased their productivity 2.4% that iteration.  A better way to calculate acceleration is to look at the difference in velocity between multiple iterations as this will help to smooth out the numbers over time because as you see in the table the velocity will fluctuate naturally over time (something scientists might refer to as noise).  Let’s calculate acceleration over 5 iterations instead of just one, in this case comparing the differences in velocity from iteration 6 to iteration 10.  For Team A the acceleration would be (23-20)/20 = 15% and for Team B (40-45)/45 = -11.1% during the 5 iteration period, or 3% and -3.7% respectively on average per iteration.

Normalizing Acceleration for Team Size

The calculations that we performed above assumed that everything on the two teams remained the same. That assumption is likely a bit naïve.  It could very well be that people joined or left either of those teams, something that would clearly impact the team’s velocity and therefore it’s acceleration.  Let’s work through an example.  We’ve expanded the first table to include the size of the team each iteration.  We’ve also added a column showing the average velocity per person per iteration for each team, calculated by dividing the velocity by the team size for that iteration.  Taking the effect of team size into account, the average acceleration between the last five iterations for Team A is (1.9-1.8)/1.8/5 = 1.1% and for Team B is (5-5)/5/5 = 0.

Similarly, perhaps there was a holiday during one iteration. When there are ten working days per iteration and you lose one or more of them due to holidays it can have a substantial impact on velocity as well.  As a result you may want to take into account the number of working days each iteration in your calculation.  You would effectively calculate average acceleration per person per day in this case.  Frankly I’m not too worried about that issue as it would affect everyone within your organization in pretty much the same way, and it’s easy to understand why there was a “blip” in the data for that iteration.

What Does Acceleration Tell You?

For how you use acceleration in practice, there are three scenarios to consider:

1. Positive acceleration. This is an indication that productivity may be rising on the team, although it does not indicate the cause of that increase.
2. Zero acceleration. This is an indication that the team’s productivity is remaining flat, and that perhaps they should consider doing retrospectives regularly and then act on the results from those retrospectives. Better yet they can “dial up” their process improvement efforts by adopting something along the lines of the Disciplined Agile Framework.
3. Negative acceleration. If the acceleration is negative then productivity on the team is going down, likely an indicator of quality and/or team work problems.

Of course it’s not wise to govern simply by the numbers, so instead of assuming what is going on we would rather go and talk with the people on the two teams. Doing so you 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 you might want to help team A share their learnings with other teams.

Monetizing Acceleration

This is fairly straightforward to do. For example, assume your acceleration is 0.7%, that there are five people on the team, your annual burdened cost per person is $150,000 (your senior management staff should be able to tell you what this number is), and that you have two week iterations. So, per iteration the average burdened cost per person must be $150,000/26 = $5,770. Productivity improvement per iteration for this team must be $5,770 * 5 * .007 = $202. If the acceleration stayed constant at 0.7% the overall productivity improvement for the year would be (1.007)^26 (assuming the team works all 52 weeks of the year) which would be 1.198 or 19.8%. This would be a savings of $148,500 (pretty much the equivalent of one new person).

Another approach is calculate the acceleration for the year by comparing the velocity from the beginning of the year to the end of the year (note that you want to avoid comparing iterations near any major holidays). So, if the team velocity the first week of February 2015 was 20 points, the same team’s velocity the first week of February 2016 was 23 points, that’s an acceleration of (23-20)/20 = 15% over a one year period, for a savings of $112,500.

Advantages of the Acceleration Metric

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. We worked through two common variations earlier, 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.  Assuming that the team hasn’t decided to take a #NoEstimates approach
3. It is easy to automate. For example, most agile management tools (e.g. VersionOne, Rally, Jira, Microsoft TFS) calculate velocity automatically from their work item list/product backlog and do velocity trend reporting via their team dashboard functionality. This trend reporting is effectively a visual representation of the team’s acceleration (or deceleration as the case may be).
4. You can easily adjust for changing team size.
5. You can easily monetize this metric.
6. It is unitless. The “units” are % change in points per iteration, or % change in points per time period depending on the way that you want to look at it. Because it’s a percentage you can use it as a basis of comparison.
7. You apply this across a department. It is fairly straightforward to roll up the acceleration of project teams into an overall acceleration measure for a larger program or portfolio simply by taking a weighted average based on team size. However, this is only applicable to teams that are in a position to report an accurate acceleration (the agile and iterative teams) and of course are willing to do so.

Potential Disadvantages of Acceleration

Of course, nothing is perfect, and there are a few potential disadvantages:

1. It can be gamed. Acceleration is derived from velocity which in turn is derived from manually-collected measures, and anything gathered manually can be easily gamed.
2. 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!
3. 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 we doubt very highly that as an industry we understand.

We hope that you’ve found this blog post valuable.

The Disciplined Agile (DA) toolkit describes strategies for how an organization’s IT group can support a lean enterprise.  An important part of this is to have an effective IT operations strategy, and to do that the people involved need to have what we call a “lean IT operations mindset.”  The philosophies behind such a mindset include:

1. Run a trustworthy IT ecosystem.  At a high level the goal is to “keep the lights on.”  At a detailed level anyone responsible for IT operations wants to run an IT ecosystem that is sufficiently secure, resilient, available, performant, usable, and environmentally friendly.  Part of running a trustworthy ecosystem is monitoring running services so as to identify and hopefully avoid potential problems before they occur.  For some systems, and perhaps for your IT ecosystem as a whole, you may have service level agreements (SLAs) in place with your end users that guarantee a minimum level of trustworthiness.
2. Focus on the strategic (long-term) over the tactical (short-term).  Anyone responsible for IT operations needs to have a very good understanding between the long-term implications of a decision versus the short-term conveniences.  A classic example of this right now is the preference of people building micro-services to use what they believe to be the best technologies for each service.  This makes a lot of sense from the narrow viewpoint of that service and it often proves to be incredibly convenient, and fun, for the developers because they often get to work with new technologies.  However, from an operational point of view you end up with a mishmash of technologies that must be operated and evolved over time, resulting in a potential maintenance nightmare.  Yes, you will still make some short-term decisions but you should do so intelligently.  Too great a focus on the long term results in a stagnant IT ecosystem, too great a focus on short-term decisions results in operations teams who spend all their time fighting fires.  The long-term technical vision for your organization is developed by your Enterprise Architecture efforts and the long-term business vision comes from your Product Management activities.
3. Streamline the overall flow of work.  This arguably should be part of everyone’s mindset, but it is particularly important for people doing IT operations work.  IT operations has traditionally been a bottleneck in many organizations, often the result of the need to run a trustworthy ecosystem and to focus on long-term considerations, hence the need to focus on streamlining the overall flow of work. BUT, this isn’t just operational work that we need to streamline, but the overall flow of work into, within, and out of IT operations.  In this case we need a disciplined approach to DevOps that takes all aspects of the development-operations lifecycle into account, including the support of multiple development lifecycles (not just continuous delivery), the release management process, and the operational aspects of data management.  Of course, streamlining the flow of work goes beyond development-operations and is an important goal of your organization’s continuous improvement strategy.
4. Help end-users succeed.  An important goal of people performing operations activities is to ensure that your end users are successfully using your IT systems.  It doesn’t matter how well your systems are built, or how trustworthy they are, if your end users are unable or unwilling to use them effectively.  End users are going to need help – you need to be prepared to provide a support function.
5. Standardization without stagnation.  The more standardized your IT ecosystem is the easier it will be to run, to release new functionality into, and to find and fix problems if they should arise.  However, too much standardization can lead to stagnation where it becomes very difficult to evolve your ecosystem.  You will need to work very closely with people performing enterprise architecture and product management activities to ensure that you understand the long term vision and are working towards it.
6. Regulate releases into production.   Most DevOps strategies reflect the viewpoint of a single product team.  But what about the viewpoint of your overall IT ecosystem, which may comprise hundreds of products?  An interesting question to ask is what is the WIP limit for releases across your overall ecosystem?  In other words, what rate of change can your infrastructure, and your stakeholder community, bear?  In the Disciplined Agile (DA) toolkit this philosophy is an important driver of the Release Management process blade.  Furthermore, some regulatory compliance regimes call out a separation of concerns pertaining to release management – the people building a product are not allowed to release the product into production, someone else must make that decision and do the work (even if “the work” is merely pressing a button to run a script).
7. Sufficient documentation.  Yes, there will be some documentation maintained about your IT ecosystem.  Hopefully this documentation is concise, accurate, and high-level.  Common documentation includes an overview(s) of your infrastructure, release procedures (even if fully automated, there’s still some overview documentation and training), and high-level views of critical aspects of your infrastructure including security, data architecture, and network architecture.  Organizations that operate in regulated industries will of course need to comply to the documentation requirements of the appropriate regulations.  When infrastructure components are discoverable and self-documenting there is a lesser need for external documentation, but there is still a need.  Any documentation that you do create should be maintained under configuration management (CM) control.

Future blog postings in this series about IT operations and support will explore topics such as why you need IT operations and support, what activities you perform, and the workflow of doing such.

On May 17 2016 I gave a webinar entitled Agile Enterprise Architecture: Disciplined and Pragmatic Strategies (at this link you can watch a recording and download a PDF of the slides). During the webinar I received many questions, some of which we had time to answer but some which we did not.  Regardless, here are all of the questions and my answers.  I’ve organized them into the following topics:

1. Long vs. Short Term
2. Deferring Commitment
3. Transitioning to Agile EA
4. General

1. Long vs. Short Term

What about longer term? How do you see the role of EA on portfolio creation?  As you can see in Disciplined Agile’s Enterprise Architecture process blade one of the primary tasks of the EA activity is to consider the longer term. The enterprise architects will collaborate to do so, and will help bring their vision to their stakeholders in various ways.  As you can see in the workflow, the EAs will interact with the Portfolio Management effort (and many others).

How do you balance the needs of today vs. the needs of tomorrow? Would you wait for business to identify it as a priority, which may be too late… or look to get ahead of the curve and build something that can scale for anticipated growth? Experienced enterprise architects will definitely think about the long term needs of the organization. Disciplined Agile EAs will do so but will wait to act to the most appropriate time to do so.

2. Deferring Commitment

Can you point us to some places to read more about deferred commit? Deferring commitment to the last most responsible moment is a concept that comes from lean software development. I recommend the writings of Mary and Tom Poppendieck as well as the book SDLC 3 by Mark Kennaley.

If we defer commitment, how about if we need infrastructure, procurement and so on to implement that architecture? This deferring will delay the entire implementation? No. The advice is to defer commitment to the last most responsible moment.  You need to understand the needs of your stakeholders, which in Disciplined Agile include a wide range of people, and then act accordingly. The problem is that traditionalists will act too early and thus add unnecessary risk.

A good observation from Valentin Tudor-Mocanu is that to be able to defer decisions we need a design that separates the concerns (adaptive design).

3. Transitioning to Agile EA

Is there a strategy to change the mindset of enterprise architects on a large organization?  Yes. It first begins with education.  We offer a one-day workshop called Agile Enterprise Architecture: Disciplined and Pragmatic Strategies that does a very good job of working through the fundamentals.  The next step is coaching of the EA team themselves, and of the teams that they interact with, to help them gain the mindset and habits required to work in a more effective agile/lean manner.  We also provide such coaching services.

One specific question related to a service or consulting organization: One of the specific requirements for us to is to deliver architecture as a deliverable. How can agile can help us?  Can we apply sprints there?  Can we apply any architecture principles? I’ll assume you meant an architecture model as a deliverable. The answer is yes, you can easily create an architecture model in an agile manner. I highly suggest that you visit the Agile Modeling site and read the advice about agile architecture strategies and to agile documentation strategies.

4. General

Can you talk about metrics in agile EA and Architecture in general?  In the Disciplined Agile (DA) toolkit we suggest that you adopt a lightweight Goal-Question-Metric (GQM) approach to your metrics strategy. The fundamental idea behind GQM is that you first identify a goal that you would like to achieve, a set of questions whose answers are pertinent to determining how well you’re achieving that goal, and then the metric(s) that could help you to answer each question. In short, the metrics that you gather will vary based on your need.

Given that Feedback cycle plays an important role, why does DAD say “Reduce feedback cycle”? Is there a pre-defined cycle frequency?  You should find the blog posting Reducing the feedback cycle requires discipline to be an interesting read.

Some forms of architecture (UX/UI) need a different cadence than the delivery team follows. What is your recommendation for handling this… UX research, etc? I disagree with your premise. I’ve heard this claim in the past and it’s never held water with me.  About 10 years ago I wrote an article entitled Introduction to Agile Usability that overviews how UX activities can appear in the agile lifecycle.  The Lean UX community has clearly gone further than what I originally wrote so you might want to go poking around on the web a bit.

When the business case says “many years before payback”, doesn’t that usually mean that the business case is missing some important elements? (or that the org is really small) ?  My experience is that the business case is usually crap in these situations. There in fact a few things in the software world that may have a multi-year payback period, operating systems come to mind, but they are more the exception to the rule.  The problem with multi-year payback schemes in the software world is that the ecosystem changes so quickly.  During the several years it takes for payback your needs change, there are new options on the market, your organization structure and direction may change, and so on.

I realize I’m asking a history question here, but regarding deferring commitment, a superb method for this that I have often used in the past comes from RUP: architecture mechanisms. (I should know this but) Is this in DAD?  If you read the Enterprise Architecture process blade article you will see that it supports several strategies for capturing and communicating EA ideas such as reference architectures, models, architectural runways, interfaces, and many others. You might also find the Reuse Engineering process blade to be of interest.

Governance is a common thread throughout all aspects of the Disciplined Agile (DA) tool kit. Delivery governance activities were built right into Disciplined Agile Delivery (DAD) v1.x, each of the process blades include a governance process factor, and there is an IT Governance process blade that coordinates all IT governance activities.

The following process goal diagram overviews the potential activities associated with a disciplined approach to IT governance.  These activities are typically performed by a variety of people within your organization. In DA each of the process blades includes activities around governing the activities encapsulated by that blade. For example, the Enterprise Architecture blade includes architectural governance activities and the Data Management blade includes data/information governance activities.

The process factors that you need to consider for IT governance are:

1. Governance view. There are many potential aspects, or perhaps subsets, to IT governance including security governance, data governance, delivery governance, and more. Too many organizations make the mistake of treating each of these issues separately, which is easy enough to do given the different focus of each one. The Disciplined Agile toolkit promotes a more holistic, integrated view that results in a streamlined, consistent, and effective governance strategy. Another common mistake is to focus on portfolio governance over other aspects and have your Portfolio and Project Management Office (PPMO) be responsible for IT governance. PPMO-led governance efforts tend to result in documentation-heavy, bureaucratic strategies instead of lean, risk-based approaches.
2. Develop metrics. Metrics define the measurements that you will take to gain insight into what has happened, what is happening, and hopefully what may happen in the future. The least effective approach to metrics is to have a standard set that all teams are expected to collect whereas the most effective is a context-sensitive approach such as a light-weight implementation of Goal Question Metric (GQM).
3. Measure. The measures themselves can be collected either manually or automatically (usually as the result of tool or system usage). We have found that a combination of the two is required – although automated metrics are inexpensive, accurate, and real-time you cannot always automate all of the measurements that you need to collect.
4. Monitor. Information radiators are sufficient in smaller organizations, but automated dashboards in combination with direct interaction with teams are also needed in modern enterprises. Traditional strategies, such as status reports or status meetings, do not prove to be effective in practice nor do they provide an honest assessment of what is actually occurring.
5. Guidance detail. An easy and important way to support governance within your organization is to have commonly accepted guidance, including standards and guidelines, for teams to follow. We suggest that you keep this guidance lightweight, starting with high-level rules but aiming towards principles whenever possible.
6. Develop guidance. Guidance is ideally developed collaboratively with a combination of practitioners and experienced enterprise IT professionals who understand the bigger picture.
7. Define roles and responsibilities. The definition of roles and responsibilities is an important aspect of your overall governance strategy as it describes what is expected of people. We’ve found that the most effective way to do this is to start with the roles and responsibilities described in the Disciplined Agile (DA) toolkit and then collaboratively evolve them from there. The framework ha both delivery team roles as well as enterprise IT roles defined.
8. Manage IT risk. Risk management for the entire IT portfolio, including both in-progress development teams as well as operational risks. Small risks on individual teams can add up to a large risk across your organization. For example, if many teams adopt a new and relatively unproven framework and that framework is then abandoned by its creators (think about how many open source projects or new companies flounder) then you have a serious problem. Similarly, when multiple teams start addressing a similar business opportunity and that line of business dries up or is legislated away.  Although risk management is addressed on delivery teams via the goal Address Risk, their focus is on risk management within a team as opposed to risk management across all of IT, or even across all of your organization.

Related Reading:

• The Lean Governance Mindset
• Lean Governance Strategies
• What is Lean IT Governance?
• Why Lean IT Governance?
• What is Agile Delivery Governance?
• Strategies that Enable Agile Governance
• Supporting Agile Delivery Team Governance
• Lean vs. Traditional IT Governance