Skip to main content

Tag: Agile

The Agile Project Manager—Fail NOW as a Strategy

Written by Robert Galen on . Posted in Articles. 8 Comments on The Agile Project Manager—Fail NOW as a Strategy

bob1

I was at a conference not that long ago speaking and sharing on various agile topics. As often happens, a young man stopped me to ask a few questions after one of my presentations. We struck up a nice conversation that eventually slipped out into the hotel corridors.

We started talking about sprint dynamics within Scrum teams and I happened to mention that I usually coach teams towards declaring their sprints a success…or pause for meaningful effect…a failure. That we do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant basing it on whether the team achieved their Sprint Goal(s).

He was visibly upset with my view. He said that they (he was working at a well-known Atlanta company) had never failed a sprint. Never! They could not nor would not use that WORD in their culture. I asked him point-blank – have you ever failed a sprint? He said of course they had. Many times. But instead of using the term fail, they used the term ‘challenged’. That way, stakeholders wouldn’t get the wrong idea and question the skills or motives of the team.

We went round-and-round for another 10-15 minutes in our discussion, but we never really settled our differences. We simply agreed to disagree. Although it wasn’t a terribly wide chasm between us, I distinctly remember walking back to my room shaking my head. I simply didn’t understand the big deal about failure. About using the word. About a team saying…we failed. In my coaching practice and in my “day jobs”, I’ve been able to steer and evolve our views so that failure is not a bad word. I.e. failure is good. Failure is ok. Failure leads to improvement.  Failure is a part of life.

So in this post, I want to discuss failure from a few perspectives. The discussion isn’t intended to be exhaustive. Instead, I just want to share some thoughts and to get you thinking about failure…how you view it in your organization, what is your tolerance for it, and re-considering your normal reactions to it. I also think this leads you towards your risk handling as well, because I think the two are inextricably linked.

bob2

Coaching to avoid failure

In his blog post from June 20, 2011, entitled Coaching is Not Letting Your Teams Fail, Giora Morein makes the case that agile coaches should be leading or guiding their teams away from failure. He brings up the analogy of a Sherpa guiding mountaineers. And yes, in the mountain climbing example I will have to agree that failure is probably not the result we want.

However, in the non-life threatening cases I think I disagree with Giora. I wholeheartedly believe that failure can actually be good for a team. I also think the role of the coach is to help a team look at their performance through two lenses. The easier of the two is the success-lens. This is the lens where you give the team positive feedback; where you tell them that they need to repeat those practices that work for them. Indeed, what practices they need to amplify and do “more of” so as to achieve greater and greater results.

These conversations are clearly easier.

But what about the failure lens? As a coach, do you provide constructive criticism? Do you show a team where they miss-stepped? Both individually and as a team? I think so. But certainly not in a malicious or heavy-handed manner. I think if you’re effectively coaching a team you must explore their errors & mistakes with equal passion and energy to how you handle their successes.

And I don’t think you do this quietly, hiding behind doors and not externally acknowledging their challenges. No. I think you approach it in a completely transparent and matter-of-fact manner. Laying the groundwork that failure is appreciated and welcome. That from it, your teams look for improvement possibilities and move forward quickly towards delivering improved results.

Agile exposure

In agile teams, there are two key ceremonies that are focused towards success & failure results from a team. In Scrum, that is the Sprint Review (demo) and the Sprint Retrospective (lessons learned). Typically, the sprint review is exposed to the world, so you might want to be careful in how you couch your failures – so that stakeholders don’t misconstrue the impact or the effort the team is putting forth. Nonetheless, I believe you should declare sprints either a success or failure as part of the introduction to the teams review.

In Scrum, it’s the Product Owners role to determine this—and it’s relative to the goal(s) the team committed to at the outset of the sprint. Hopefully those goals were flexible enough to allow the team to adjust their work focus to creatively attain it.

For example, I think a very poor sprint goal is something around the team delivering a set number of user stories—or other indicators of by-rote execution.  I think this leads to potential sand-bagging on the part of the team to hit a numeric goal rather than thinking of the true problem they’re trying to solve. Instead, I think better goals revolve around achieving some sort of demonstrated behavior that solves a specific set of customer problems.  So success is measured against how well the team met the spirit of the goal and how well they applied the agile principles in their execution.

For example, I’ve seen teams that commit to 10 user stories, but who had an extra 3 days at the end of their sprint of idle time, fail their sprint. Sure, they delivered to their commitment, but their commitment was flawed. They sandbagged and over-estimated. They also didn’t make their additional capacity available to their Product Owner and ask for more work within their sprint time-box. Instead they planned ahead or gold-plated their deliverables.

If also seen teams that commit to 10 stories, but deliver 7 have a very successful sprint. In it they work hard against complexity and adversity. They’re incredibly transparent and engage their Product Owner in making daily adjustments on priority vs. their new understanding of capacity. And as a team, while they didn’t deliver the originally perceived quantity, what they did deliver aligned with their goals and met the spirit of the Product Owners intent.

Both of these cases should be discussed in the teams’ retrospective and ways to improve discussed. Not small ways and not ignoring the first teams’ behavioral problems. No. All of it—the good, the bad (mistakes & failures), and significant improvement ideas will be discussed in order for the team to decide what points are worthy of their improvement focus in the very next sprint.

bob3

But is failure embraced?

Continuing with my earlier coaching example, I remember not that long ago I was talking to a group of our Scrum Masters at my “day job” iContact. If you don’t know about Scrum, the Scrum Master is the primary coach & guide and agile leadership voice within the agile scrum team. They’re also responsible for maintaining core agile values within the team and for the teams’ overall performance. What I mean by that is—guiding the teams improved performance over time. Continually asking questions like—is their team improving in their overall performance? Is their velocity improving? Is their work quality improving? Is their teamwork and collaboration improving? And, is their focus on delivered customer value improving?

So my point to the Scrum Masters was I felt we hadn’t failed in quite a while. I defined failure in this case as a sprint failure or a stop-the-line incident where a team basically ran into an impediment and needed to re-plan or re-align their sprint.

They all agreed with me that things had been going smoothly. And I received more than a few questioning stares as to why that was a problem. I tried to be careful in my reply, but my concern was that we might be playing it too safe. That we were becoming complacent in our agile practices and that we weren’t stretching ourselves enough. We weren’t taking chances. And we weren’t taking risks.

I explained that these traits are fundamental to the growth and advancement of agile teams. And the fact that we weren’t seeing failures indicated that we’ve plateaued in our growth and performance. I felt this was a problem…and I asked if they could drive more failures from the teams.

Can you imagine the remainder of this discussion?

Here I am the Director of R&D at a successful company talking to my team of Scrum Masters and asking them to drive more failure—to influence their teams towards more risk-taking and inspire more stretch goals. The point I’m trying to make is that I truly embrace failure. That I’ve learned to view it as a critical success criterion and that its absence is a problem for me. I wonder how many organizations and leaders have the same view.

The notion of “Failing Forward”

One of my favorite authors is John C. Maxwell. He’s relatively well known as a leadership coach and he’s quite a prolific author—having written more than 50 books on various leadership topics. He’s got a strong Christian background to his life and writing, so if you’re not so inclined, don’t let that put you off. He’s mastered the art of leadership.

A few years ago he published a book entitled Failing Forward—Turning Mistakes Into Stepping Stones to Success. In it he emphasizes failure as a truly transformative factor in our personal, professional, and team-based lives. But he carefully frames failure with a leaning forward posture. That is—instead of viewing failure as a negative end-state and feeling sorry for ourselves, we should embrace it as a positive learning experience. That you would be “leaning forward” in your failure—leveraging the lessons learned to improve.

I don’t think Maxwell is simply blowing positive smoke in our direction here. History is clearly littered with examples of successes that were inspired, forged, and hardened in the fire of failure—Thomas Edison being a famous example as he persevered to invent the light bulb.

In my agile coaching I consistently use the terminology “fail forward” when I discuss team-based failures. Yes, I want a team to be honest with themselves and acknowledge they failed. But I also want them to embrace their mistakes instead of getting defensive, blaming others or denying it entirely. And I want their posture to be leaning forward. Eager to try something new that will drive different results. Not afraid of failure.

I find that using this terminology helps teams to ‘get’ the nature of failure and to behave appropriately. But beyond terminology, project and functional leadership need to fully support the idea too—meaning the entire leadership team needs to be supportive of failure. There…I said it.

Wrapping Up—But, I’m a bit strange…

All of that being said, I wonder if I’ve got a strange and largely minority view towards failure? I wonder if the right response is to indeed be fearful of it.  To deny its existence.  To spend countless hours trying to predict it.  To never mention it in public. Are those and similar actions the right responses?

To that end, I’m closing this post with a request of all readers. I’ve put together a small, focused survey that I’d like you to take. I know, I know, you’re busy. But I really think your insights will be helpful here.  The survey is focused on gathering a view towards organizational, group/team, and individual acceptance of failure and risk. I’m trying to get to a root understanding of acceptance and also the root cause for those views. While I’m particularly interested in agile teams, don’t let your lack of agile experience prevent you from responding.

Enter Survey Here…

I also request that readers weigh-in with your blog comments too. What I’ll do is collect comments and survey responses, consolidate them, and share them in a future blog post.

I wonder if the survey will be a failure?

Don’t forget to leave your comments below.

Three Baby Steps Toward Agile Requirements Management

Written by Kurt Solarte on . Posted in Articles. 8 Comments on Three Baby Steps Toward Agile Requirements Management

If you are beginning to consider a move to more agile methods, you may be looking for a set of ‘best practices’ for agile requirements elicitation and agile requirements management. What you will likely find is many prescriptive and detailed ‘best practices,’ which I have personally found to be situational at best, and often just too much to consume for an organization new to the concepts. What I propose to offer in this post are a few ‘baby steps’ that can help an organization move toward an agile environment and prepare for some of the more prescriptive methods like SCRUM or eXtreme programming (XP).

When making a move toward agile methods, there are three main recommendations that I believe should be considered to prepare for a more agile requirements practice, and a team as a whole.

  1. Collaboration ─ While this is obviously a good idea in all methods of requirements management and all stages of a project lifecycle, it is an essential element to agile methods and agile requirements management.
  2. Embrace Change ─ This is almost a counter-intuitive step for many business analysts. To be agile in requirements management, we must acknowledge change happens, embrace it, and make it part of our process.
  3. Support of upper management ─ Becoming agile is an organizational change as much as a development practice, and without clear support from upper management, this change will be difficult, if not impossible.

Recommending good collaboration is a bit like recommending good work ethic; it seems as if it should go without saying. However, for organizations used to a very siloed waterfall method, real collaboration as a standard operating procedure may have fallen by the wayside. It can become easy in a waterfall method to simply over-document deliverables and blindly send them to the next team. In an agile method, an organization will begin to keep ‘living documents’ that constantly change and grow ─ this requires true collaboration and teaming. In order to include all members of the project team and stakeholders properly, an organization must not only take on more inclusive methods, but must educate all associated people on the use of the method, including management and stakeholders. If one expects individuals to be involved, the individuals must know how, why, and when they are expected be involved. Simply said, to create an inclusive method, all individuals associated with the project must feel and be encouraged to be involved. One simple step many larger organizations have found useful is the adoption of stakeholders’ terminology. Often in agile methods, we get very focused on the new names, terms, and roles ─ all at the detriment to collaboration. Many stakeholders will feel more comfortable with requirements, time periods, and project roles being expressed in their own terminology. This should be seen by the project team as a minor secession for the sake of greater collaboration.

Embrace Change. To many Business Analysts and Project Managers, this will seem counter-intuitive. As professional BAs and PMs, we have been taught to identify all requirements and lock down the scope. However, we all know change does happen, and what often defines the success of a project is how we deal with that change. Traditionally, an organization would manage this change with some sort of project or scope change management process, which gives a structure to altering requirements that are typically fully elicited. In agile methods, organizations acknowledge that change is constant in technology projects, and move to embrace that change. To make steps toward agility, an organization may need to change their requirements elicitation methods. The elicitation can begin with very broad requirements that outline a general scope, do some high-level requirements modelling, prioritize what has been captured, and prepare the team to change as needed. Once the broad requirements are documented and ranked, the team can then begin to add further detail to requirements in an ordered fashion. This means the stakeholders will give detail as it is needed, and the team will change documentation as details emerge. The stakeholders know their priorities and requirements will change, and the project team knows the project documentation is ‘alive’ and changing as the project moves on, and as the need for detail requires.

While the above-detailed steps are important ways to ease into agile, arguably the most necessary step is getting upper management support. The management lines for both the project teams and the stakeholders must understand the use of agile methods is an organizational change, and not just a development method. These management lines must fully comprehend the concepts behind embracing change, increasing collaboration, and the notion of practicing constant requirements prioritization. As with many successful organizational changes, the use of ‘on the ground’ champions of the new process are important, but a clear message of support by company leadership is imperative. A project kick-off that includes an executive saying a few words of support for the new methods and mentioning that management is watching for this to be a successful implementation will go a long way to drown out the voices of the detractors.

As an organization strives to become agile, it is important to remember to be agile in the implementation of agile. Meaning, only take on as much agile process and change as your organization can handle in each ‘sprint,’ or short change window; and only keep the agile processes needed to improve implementation of technology projects. Organizations can often lose focus of their underlying purpose for adopting agile methods, and begin to focus on ‘becoming agile.’ There is not a prize or reward that comes with completely adopting any particular agile method, so look to embrace the parts of agile methods you need to find your success, and question anything else — because that is truly becoming agile.

Don’t forget to leave your comments below.

Kurt Solarte is a Managing Consultant working for IBM Australia in Sydney; focusing on Agile Development methods. Kurt recently spent eight years with IBM Global Business Services in the U.Ss as a Sr. Business Analyst; where he specialized in keeping business analysis alive and relevant in the agile delivery of eCommerce, web portal, and business analytics projects.

Agile Project Management—Engaging Your Customer!

Written by Robert Galen on . Posted in Articles. 2 Comments on Agile Project Management—Engaging Your Customer!

RG2The agile methods come at software development by challenging many of our status quo practices. The first one is the engagement level of the ‘customer’. It’s my experience that most waterfall or traditional projects allow the customer to disengage after they start the project and provide an initial version of the requirements. After some time…later…they appear at the end of the project to receive their prize. Usually they’re disappointed in the end result—finding the functionality not living up to their original vision & expectations.

This sort of “end-points” behavior leads to many project failures due to a lack of clear communications, misunderstanding, and missed expectations.

But it has a simple solution. The customer should stay engaged during the entire project. They should be available for trade-off discussions and for demo’s. They should provide ongoing feedback on interim deliverables. They should even understand the teams’ capabilities and implementation challenges. In a word, they should become a “partner” to the team and not simply a “stakeholder”. They need to have continuous skin in the game if the project heads south and they need to be a part of trade-off and scope adjustment decisions.

The agile methods have several ceremonies or tactics that are intended to draw the customer into the team; to foster their inclusion and to gain their insights. In this post I want to review and emphasize the importance of these practices and the need for overall customer engagement.

Backlog Grooming

You all know that a prioritized backlog of work items (features, tasks, key functional and non-functional requirements) is what drives the agile ‘machine’. The list is dynamic in nature with items being added, removed and changed nearly continuously during the lifetime of an agile project.

Many represent the central nature of the backlog as a pyramid or iceberg. It follows then that at the ‘tip’, the highest priority items are found. They are also defined at the clearest and finest level of granularity. In other words, these items are ‘ready’ for execution. The team has sized them and broken them down. They have talked about them several times as they’ve done this.

This activity is typically called ‘grooming’ the backlog. It’s where the team repeatedly revisits the backlog, refining it from multiple perspectives and getting elements ready for execution. The Scrum Product Backlog is not only a list of features, but it’s effectively a work breakdown structure for all of the work necessary to complete a product or project release.

By involving your customers and stakeholders in backlog grooming and making it transparent, you’re engaging them at a base level of requirement management and planning. Both are areas where your transparency can and should pay-off in increased interaction and feedback on the backlog—pre execution.

It also results in a better understanding on the part of the stakeholders on the level of complexity and difficulty that the team is encountering. I probably hear pushback 3-5 times in every grooming session around how easy they thought a feature would be to complete. Why, we almost do it now, so it can’t take more than an hour or so to extend the feature…right?

Then the team, usually patiently, tries to explain why the design is more complex and how the estimate for the story is extended by the “real world” they deal with every day. Or why a single day implementation might need three days of testing because of data security concerns. So having the customer involved in grooming and planning (next) can really help them understand why things take as long as they do, while also drawing them into powerful trade-off discussions.

Sprint Planning

Rarely does an approach to software development include customers and stakeholders in planning the project. At least not in the nitty-gritty details of the effort. But in Scrums’ Sprint Planning ceremony the customer is welcome to attend as the team considers the work and plans their execution.

The meeting has a two-phased approach. Phase one is focused towards the Product Owner sharing the sprints’ focus with the team. They review the body of stories targeted for this sprint and answer any late-binding questions the team may have about them. Quite often, the questions vary from specific behaviors to how the team might design and implement the feature set for the sprint.

Once phase one is finished and the team fully understands the work, they then dive-in and begin to break down each of the stories into work tasks. Keep in mind that these are ALL tasks associated with the work—for example: development, testing, design, inspections & reviews, documentation, etc. Every bit of work required to deliver the story to completion is identified by the team and the effort associated (hours) are estimated.

So you might ask, how does this help the customer engage? It allows them a view into the planning & execution dynamics of the team in order to deliver on their requests. They gain a glimpse into the level of difficulty associated with each feature—where are the hard ones, fraught with risk. And conversely, where are the easier ones.

They gain insight into the strategy the team will be using to deliver the features. Who will be working on which features and why? How is the team planning on handling dependencies and overall feature testing? How are they planning on handling risks? And if the team is operating as part of a larger group, how are they interacting with other teams on dependencies, integration, and collaboration?

In a word, the plans are totally transparent and open for discussion and adjustment. The team simply wants to deliver on its commitments, so constructive ideas are welcome—especially the empathy that stakeholders should realize by becoming part of the teams’ planning.

You see—software is rarely as simple or easy as most bystanders believe.

RG1

Daily Stand-up

All of the agile methods have the notion of a daily team meeting for sharing progress, challenges and making real-time adjustments to the teams’ committed goals. In Scrum this is known as the Daily Scrum and it’s where a customer can gain real-time insight into the “inner workings” of their agile team(s).

I remember a team implementing some features in an eCommerce application. To her credit, their VP of European Operations would attend the meetings whenever possible as they were developing the interfaces to Amazon UK. She would listen intently to the discussions, but wouldn’t interrupt the team with questions as she was a compliant ‘chicken’ in the stand-up meeting.

However, after the more difficult conversations in some of their daily scrums, she would pull me aside and ask me questions regarding what she had ‘heard’ in the stand-up. Were they in trouble? How could she help? And, could they adjust some of their scope commitments in order to assist the team? Were very typical questions she asked. In some cases, her concerns were unfounded. In others, they were absolutely right on.

The stand-up was her window into the teams’ work dynamics that she had never had before. No longer was she relying on written or e-mail status reports that were interpretations of progress. No! Now she received unfiltered, raw data from the team themselves. She encountered the highs and lows. She clearly saw the teams’ challenges and, more importantly, how they approached resolving them.

She didn’t need a report to tell her where the risks were. Instead, she viscerally understood them by interacting with the team. She also saw the opportunities present themselves where she could assist the team in making adjustments while still achieving their & her overall goals.

It was incredibly powerful and frightening at the same time. It enticed, no encouraged, no demanded her to engage as an ‘owner’ with the team.

Sprint Review or Demo

One of the core agile manifesto points is “working software over jabbering about working software”, and I paraphrased a bit here. You see an incredible emphasis in agile teams, and I think it appropriate, to discuss most of your designs, requirements, and product commentary while looking at working software. There’s literally nothing else like it.

In Scrum, there is a Sprint Review or demo ceremony at the end of each sprint or iteration. In the demo, the team is responsible for showing off their working software that was focused towards their established sprint goal(s).

This ceremony is a “big deal” in Scrum teams. At iContact for example, we have sprint reviews for our teams every three weeks. We have them in our largest conference room. We literally invite the entire company (yes, we’re relatively small) to the event. Usually over half of our C-level team is in attendance and the room is typically standing room only.

Each team takes its turn to demonstrate their efforts for the past sprint. Team members all get a shot at speaking to their efforts. The audience is engaged. Asking questions and providing immediate feedback on the functions and features demonstrated.

Often the feedback extends beyond the demo. Folks will follow the team back to their seating areas and provide additional feedback and/or ask to see a particular feature again. I often see our CEO whispering his reactions to our product managers during and after the demo as he guides the vision he’s personally looking for in our product.

But beyond feedback for our teams, it shares information with our sales, customer support, and account managers. They become familiar with what’s being developed in real-time and can communicate those “coming attractions” directly to our customers.

Wrapping Up

One of the keys to engaging the customer is showing them you’re listening to their feedback. That it matters to you and you’ll take relatively immediate action on it. This loop of (Listen To Feedback – Develop/Change Software – Demonstrate – Listen Again) is a wonderful device for agile teams to assure they’re on the right track.

It also draws in their customers. It engages them in the process because they feel more like a partner in the teams’ efforts. Now not all customers will embrace this behavior. Traditional customers will be taken aback and you’ll hear excuses—mostly that they don’t have the time for it. You’ll need to be patient and, over time, draw them into your efforts. Working software that demonstrates solutions to their most challenging problems can be…well intoxicating.

Agile project managers maintain their teams’ focus on the heartbeat of delivering value and work hard to PULL the customer into the fray. Why? Because it’s their software, they need to care, and you need their feedback. So just do it!

Don’t forget to leave your comments below.

Managing Schedule Flaws Using Agile Methods

Written by Brian Button on . Posted in Articles. 4 Comments on Managing Schedule Flaws Using Agile Methods

Aug3FeatSoftware projects rarely come in both on time and on budget, leading to dissatisfied end users. DeMarco and Lister, authors of Waltzing with Bears: Managing Risk on Software Projects, discuss five different risks associated with software project management, including schedule flaws as one of them.

In this article, we’ll discuss several symptoms and causes of schedule flaws, present metrics and diagrams that can be used to track your team’s progress against its schedule, and describe Agile ways to address these risks.

CAUSES

Schedule flaws can be caused by the unpredictability of the environment around a project or by the inherent difficulty in predicting the time significant pieces of software will take to implement.

Estimation difficulties are just a fact. We rarely create the same systems twice, so each new project is truly new. Each has their own problems, solutions, and complexities. No software plan survives its first contact with the customer, leading to a situation where your plan needs to evolve to match changing reality. This is the risk that we’ll focus on below.

SYMPTOMS

Teams that suffer from schedule flaws often exhibit one or more of the following five symptoms:

1. Frequent change requests from customers and stakeholders
Customers and stakeholders learn more about the system being built as it takes shape. Based on their new knowledge, stakeholders often change their minds about existing requirements or adding new requirements.

2. Unreliable estimates
Every interesting piece of software that gets built is inherently something new. Because of this, the time to build individual pieces is difficult to estimate accurately.

3. Large amount of “off the books” work
All teams have “extra” work to do that is never written down, be it testing, documentation, or just finishing the “edge cases” of features. This work has to happen, but it appears on no one’s schedule.

4. Uncertain quality
Inadequate or late testing leaves the quality of the system in doubt, allowing defects to be found in final testing. Since these defects are unknown until the last round of testing, their effect on the schedule is unknown.

5. Matrixed team members
Team members that are shared among multiple teams can become bottlenecks. Waiting for them to become available can cause delays in deliverables.

METRICS

It’s important to have a good set of historical metrics to understand the effects the above causes of schedule flaws have on your project. The most basic metrics used to track a project’s progress and to illustrate schedule flaws are two variations of burn charts. The first, a burndown chart, graphs work completed versus time, sometimes with both actual and planned work/timelines shown. A burnup chart shows the same information, additionally showing work added to a project over time. A project is on-track as long as the actual progress and planned progress shown on either type of chart match. A solid metric describing progress against your desired delivery date is the most critical measurement for a project to keep, since it is the leading indicator of whether you have a problem.

In Figure 1, Example Burn Down Chart, we can see a project that spent several weeks basically tracking the ideal curve down their burndown chart. Sudden, though, the project went off-track. A large amount of work was added to the release, as can be inferred by the upwards slope of the burndown line. Scope had to be cut or time added to bring the project in successfully.

Brian1

In Figure 2, Example Burn Up Chart, the total height of any bar represents the total amount of work present in the project. The area in green represents work completed and the area in red shows work left to do. The total amount of work in scope varies as the total height changes. Here, you can see that work is being added as quickly as it is being finished, resulting in a finish line that is constantly moving to the right.

Brian2

These two graphs show the same backlog for the same project, but illustrate the different information available from each graph.

METRICS TO UNDERSTAND CAUSES

Once it is determined that the project is not keeping to its schedule, more investigation must be done to determine why that is. Below are several metrics that can be used to learn about underlying causes of schedule flaws.

1. Changing Capacity
Teams that do not have a stable amount of working hours can see their productivity rise and fall as their capacity changes. Measuring the number of available hours across the entire team will provide insight as to whether this is the cause of the schedule flaw. If it is, you’ll see velocity vary directly with capacity.

Brian3

2. Poor Estimation Accuracy
The most important part of looking at estimation accuracy is identifying stories that are outliers from the main body of the estimates and to understand what made them off by so much. When the outliers are found, some level of root cause analysis can be done to understand if there was a special reason for that variance or if there is something systemically wrong with the estimates that made a group of them drastically wrong.

For example, on a recent project I managed, we tracked estimates versus actuals. Every story was estimated in “points,” where a single point corresponded to a half-day of work. When graphed, we saw how rapidly the distribution of results changed as the estimated size of each story increased.

In Figure 4, Estimates versus Actuals for 1 Point Stories, we can see a graph of our results. The X-axis represents the actual number of hours taken by a story, while the Y-axis shows how many stories had the same actual duration. The majority of stories were six hours or fewer, with many of them being shorter than four hours — we didn’t have fractional points, so one point was a low as we could go. There were a few outliers, though, and we talked about the special causes of them. In some cases, there were defects or poorly written code in the inherited codebase; in others the requirements were unclear early and grew as they were better understood.

Brian4

As the size of the story estimates increased, even to two points, the quality of the estimates began to drop. In Figure 5, Estimates versus Actuals for 2 Point Stories, you can see a larger spread of actuals resulting from the same types of issues in the first case, with misunderstood requirements playing a larger part in the inaccuracies as estimates grew.

Brian5

3. Uncertain Quality and “Off the Books” Work
On teams with whom I’ve been associated, these two causes are known by everyone on the team but acknowledged by no one. The best way to understand the effects of these two flaws is for a manager to work closely enough with the team to feel the undercurrent of tension that people are surely experiencing. Faced with this undercurrent, they must start conversations about quality and completeness and readiness. The longer the team waits to have these conversations, the more unpleasant the surprise at the project’s end.

AGILE PLANNING & ROADMAPS 

Each of these causes of schedule flaws represent risks to a project. Agile teams manage this risk by changing the role and method of planning versus more traditionally run projects.

Agile teams plan differently. They absolutely have a plan and a schedule, but the plan is encouraged to change over time as learning happens. Planning becomes a commonplace activity, performed at different levels and at different rhythms throughout a project. These different levels of planning serve to address each of the issues described above in specific ways.

At the highest levels, Agile teams plan to deliver capabilities to customers at some agreed-upon schedule. These capabilities are loosely defined to leave as much wiggle room as possible while giving as complete a description of the feature as possible. This wiggle room sounds absurd on the surface, but it is actually a key ingredient of what makes this style of planning so successful.

The output of this planning is a roadmap of capabilities that will be delivered at specified times in the future, with some amount of detail about what each capability will provide. That should be enough for long-range planning, marketing, and sales. They have a rough roadmap and a near certain guarantee of delivery.

By keeping this long-range planning at a very high level, people are free to make changes in the plan at this point, whether from changing market forces or in reaction to a schedule flaw, with little cost and with little risk. This level of planning happens several times a year.

PLANNING & EXECUTION

One level down from roadmap/portfolio level planning is Release Planning. This is when teams solidify the features they are going to deliver typically 4–12 weeks out. Capabilities from the roadmap are selected and broken down into smaller, more understandable pieces, called epics. Epics represent coherent, releasable features in an application that are more defined than larger capabilities but still larger than what can be implemented. The epics selected first tend to be the ones that provide the greatest value to business stakeholders, risk reduction, or learning for an organization. Lower-valued features are pushed later in the project schedule, or perhaps fall off completely if their value never becomes high enough to justify the cost of developing them.

The epics are estimated by the practitioners who are going to implement them, and are prioritized according to their importance to the release. This level of planning happens once per release: 4–12 times a year.

The most frequent form of planning, iteration planning, happens once every week or two and is where the rubber meets the road. A small number of epics are brought to the team, where they are broken into “user stories,” small bits of functionality that provide some portion of the epics’ features.

During iteration planning, the team discusses the low-level business details of the work and builds a plan for how they are going to implement this set of user stories. Each story is defined as concretely as possible, including a set of acceptance criteria that detail what it means for that story to be done. At this point, these finely grained units of work are generally a day or less of work. As described above, smaller stories are estimated more accurately.

As part of the capacity planning used during iteration planning, historical values for the capacity of the team are tracked and used to limit the amount of work promised for the one- to two-week time box. This regular rhythm of planning, committing, executing, and delivering gives the project a heartbeat that allows its progress to be measured and tracked.

The final execution stage is where quality is monitored and created every day. Quality is never uncertain on a team like this. Each move that a team member makes is done with an eye on producing quality. There are automated tests around security, load, scalability, and performance. Most tests are run dozens of times a day and at least once per night. The system is continuously built, deployed, and tested.

Obviously, there is effort expended to reach these quality levels, but the benefit is that a team can be ready to ship code at any time. Every feature that is done is coded, tested at the feature and system level, all needed documentation is written, and it is ready to go. This lets progress through the project be tracked in terms of completed value, and allows for early and incremental delivery of working functionality.

By focusing on the agile practices and metrics detailed in this article, teams can identify and manage the risks that cause schedule flaws. These metrics give visibility to the risks, while the practices give teams tools to manage them. Between the combination of the two, teams can deliver great value to their stakeholders quickly, effectively, and with high quality.

Don’t forget to leave your comments below.

Brian Button is the VP of Engineering and Director of Agile Methods at Asynchrony Solutions, Inc. a leader in Agile software development. Brian instituted the Asynchrony Center of Excellence, leading a group of agile trainers and mentors that train, innovate, and evangelize agile to internal staff and project teams at outside corporations.


Agility is Essential but Process is Not

Written by George Pitagorsky on . Posted in Articles. 6 Comments on Agility is Essential but Process is Not

FEATUREJuly201A recent response to a blog post said that “agility is essential but process is not.”

Let’s be clear about the relationship between process and agility. There is always a process — a set of steps to accomplish something. Agility is an attribute of process.

A process may be agile or rigid to one degree or another, more or less heavy or light, defined or not, effective or ineffective.

Agility is Necessary

A process that is agile is more likely to be effective than one that is rigid, particularly when what is being done is complex and subject to change. Why? Because the ability to adapt is necessary if objectives are to be met and people’s expectations are to be satisfied, especially in a volatile environment in which there is uncertainty about requirements. 

For example, if you are trying to create a web site to satisfy the needs of an organization, attempting to document all the requirements fully before beginning the development is often not an effective approach. If an IT process is followed so that requirements documents must be completed in great detail and accepted, and every change thereafter must go through a formal change control process, there is high probability that the client will be frustrated as will the project team. Why would anyone follow such a process? Because they are codified and institutionalized; they are the rules.

Agility in this case would enable developers to work directly with clients who can make decisions about functionality and format as the site is being built. Functionality would evolve as the site is delivered and put to use.

Process is Necessary

Agility without a well-defined and effective process is chaos. It risks shortsightedness — creating a product that is not easily enhanced, for example.

In the case of the website, one aspect of process is the decision-making as to whether the project should be undertaken and how it should be managed; whether to use an Agile approach, how to capture performance data (e.g., the number of hours worked on components) and report on progress, and what kind of documentation is needed.

Other aspects are the way requirements and changes are to be handled, how design constraints and reviews are to be done, who will do testing and how they will do it.

Further, a process for product planning is needed to provide, in broad brush strokes, a road map of where the development is headed.

Maintaining the Right Balance

The notion that Agile approaches are without process is just plain wrong. If you analyze a methodology like Scrum, you can clearly see that there are role definitions, prescribed techniques, tool utilization and more. These add up to a defined process.

The Right Balance

The trick is to be able to strike the right balance. The process needs to include a clear understanding of where, when and how to change the process.

If change can take place on the fly, decided by the performers themselves at the team level, then the process is highly flexible. But for this to work in an organization, there must be standards and policies to guide and constrain the change. There must be well-trained and relatively clever performers who take responsibility for their actions and recognize the need to address both short-term and long-term objectives.

Not every team or individual has the wisdom to do the right thing. Some are so focused on the needs of the moment that they make decisions that restrict future growth and sub-optimize the overall process or program that the project is part of.

It’s like the old Zen parable about keeping horses. Give them unconstrained space and they’ll wander away. Put them in too tight a pen and they’ll kick their way out or get so still that their muscles will become weak and they won’t be of much use. Put them in a large enough controlled space and they’ll be happy and healthy. When they get to the fence, they’ll turn in another direction because there is no need to jump the fence.

The point is that we need constraints and defined processes but they must add value to both the project and the broader context of which the project is a part of. We need an effective, flexible process that gives people the ability to adapt to the needs of the current situation while adhering to best practices and coordinating within the bigger picture.

Don’t forget to leave your comments below.