Modified on by ScottWill
Years ago, waterfall projects would typically shun requests for new features or capabilities being added to a project that was underway. After all, project success was typically measured by conformance to “the plan” – and a new request was not part of the plan. These waterfall teams would complete the opening sentence something like this, “When we get a new feature request, we put it on our list of features for consideration in the next release.” Thus, an opportunity to respond to changing conditions, changing customer needs and expectations, or changing competitive situations in a timely manner was lost.
Other waterfall projects have tried to add the new feature in along with the work that was originally committed in “the plan,” but that would often spell disaster since teams were typically already working feverishly just to meet the original commitments. In order to add something else to an already booked plan, there were very few options – mainly overtime and/or cutting corners – neither of which is a good thing. Oh, sure, there was always a planned “buffer” added into “the plan” to account for such contingencies, but when have you ever seen it work out the way it was intended? The skeptic in me would guess rarely, if ever… These teams would complete the opening sentence something like this, “When we get a new feature request, we add it to the plan and start mandating extensive overtime.” Pretty soon, employees are burnt out, frustrated at not having a life, and begin to actively seek employment opportunities elsewhere.
Mature agile teams complete the sentence something like this: “When we get a new feature request, we see it as an opportunity to get ahead of the competition as well as make our customers happy and successful.” Typically new requests surface because of changes in the competitive landscape, changing customer needs and expectations, new market opportunities, or even some combination of these and other factors. And when these new requests arrive at the door of an agile team, there’s no drama at all, no worries about overtime, no cutting corners, no consternation about not meeting “the plan,” etc. Agile teams have great flexibility to handle new requests because they are always working on just one thing at a time – not numerous features in parallel. Waterfall teams typically worked on lots of features in parallel since all the features were committed up-front and since teams typically had to show progress on all the committed features from the very beginning of the project. Thus, if a new request arrived, there was no flexibility to drop a less important feature from the plan since everything was already underway.
Agile teams, however, work on one thing at a time. And the way they do this is by having the features rank-ordered from the most important to the least important. If a new request arrives, the team finishes working on the feature currently in progress – it then has complete freedom to begin working on the brand new request. If a particular ship-date has to be met, then the team drops the least important feature from the list and replaces it with the new request. This way, the team is always working on the most important feature and has incredible flexibility to handle changing circumstances. After all, conformance to “the plan” is not the right measure of success – meeting customer needs and adapting to changing market conditions is a much better measure of success.
To summarize, working on one thing at a time (always the highest-ranked, most important item) and getting it done before starting on something new is the most efficient and effective way to work. It also allows for the greatest flexibility – especially in markets where changes can occur lightning fast.
One thing at a time, one thing at a time, one thing at a time...
“If you’re not better this month than you were last month, don’t tell me you’re Agile!”
I forget exactly where I heard that quote but it was from someone well known in the industry that came up during a webcast I was listening to several years ago. It caught my attention and helped me start to focus more on why Continuous Improvement is considered a foundational principle of agile. My research led me back to the Agile Manifesto, specifically to the principles of the Agile Manifesto where one of the principles reads:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” [emphasis added]
No doubt you’ve heard of, and hopefully engaged in, regular reflections (sometimes called “retrospectives”). If you haven’t done so, or have tried them and not gotten much value, then I’d like to provide a few ways to help make them valuable and to help you and your organization adopt a Continuous Improvement mindset. Conversely, even if you do regularly hold reflections and find them useful, the hope is that the following is something else you can add to your “bag of tricks” and make them even more valuable and compelling.
First, we recommend that reflections occur at the end of every iteration. These meetings are team meetings and shouldn’t take more than an hour (a half-hour seems to be fairly typical in our circles).
Next, the meetings are not meant to be “gripe sessions.” Yes, sometimes a little bit of griping can be cathartic, but the goal of a reflection meeting is more than just walking away happy that you had the chance to vent your spleen… The goal is to figure out a way to improve between now and the next reflection meeting.
The meeting facilitator should just go around the table and ask everyone to list the pain points that they’re facing. The facilitator keeps a list of all the pain points brought up and, after the last person has spoken, shows a list of all the pain points raised – ranked from those with the highest number of mentions down to those with the least. The item at the top of the list is what the team focuses on since that is the one that is having the biggest negative impact on the team.
Now that the biggest pain point for the team has been identified, the team brainstorms on some specific actions to take to improve in that one area and includes those actions as part of the iteration plan for the next iteration.
At the end of the next iteration, during the reflection meeting, the team determines whether that pain point has been resolved. If not, the team brainstorms on some additional actions to take in the next iteration. The key here is to NOT start trying to solve another pain point until the first one has been solved to everyone’s satisfaction. Once the biggest pain point has been solved, only then should the team move to the next biggest pain point on the list. Lather, rinse, repeat every iteration – and soon Continuous Improvement will be the norm…
I’ll have some additional suggestions in the next post. In the meantime, please comment on your experiences with reflections, as well as on any helpful practices you’ve discovered. Thanks!
Modified on by ScottWill
When a project is big enough to have two or more teams working on the same project, we recommend that each team have its own backlog of User Stories and each team size its own stories with Story Points. Of course, this inevitably raises the idea of having each team conform to some “story point standard” so that project progress and team progress can be tracked "uniformly." Doing this more or less means that teams have to normalize story points across all the teams so that, for example, a 5-point story for one team is the same as a 5-point story for every other team on the project; an 8-point story is the same for every team, etc., etc., etc.
All I have to say to this idea is: “Ugggghhh… What a collosal waste of time!" I’ve seen teams try to do this and the effort put into trying to ensure uniformity of sizings across multiple teams is enormous.
I’m happy to report that there’s an easier way that still allows for overall project progress to be easily seen as well as individual team progress. In essence, instead of normalizing based on story points we suggest “normalizing” based on the calendar. Let me explain: let’s assume, for example, there are two teams on a project, each having its own backlog that has been sized with story points. Team A has 2000 story points on its backlog and Team B has 500. In this case you would have three burndown charts to track progress: one that’s combined (showing 2500 total points), a second one for just Team A (showing 2000 total points), and a third one for just Team B (showing just 500 points). In order to determine relative progress for Team A and Team B, you base it on the number of points completed vs. the number of iterations... Thus, if you're half-way through the project (e.g., 5 of 10 planned iterations are complete), you would expect Team A to be ~1000 points complete (50% of its total) and Team B to be ~250 points complete (50% of its total).
Where things get to be a little more complicated is when you have numerous teams working on a project (for some enterprise application projects we’ve worked with, we’ve seen over 40 teams working on the same project). With two teams, it’s fairly easy to bounce back and forth between Team A’s release burndown chart and Team B’s release burndown chart. When you have more than that, you can create a very simple chart (using any spreadsheet tool) that shows “percent calendar complete” and “percent story points complete” for each team. Following are two examples that we’ve used (they show the same data, just in different formats):
You’ll notice in the first chart that the schedule is 60% complete (the black bars) and then each team’s relative progress is shown. In the second chart, a stacked bar is used to show overall te am progress. In this made-up example, Team 1 is slightly ahead, Team 5 is slightly behind, and the other teams are perhaps struggling...
I’m sure you can think of other, different ways of showing the data, so do whatever’s most helpful. The key is that this approach is so much easier and simpler than trying to normalize the sizing of story points across multiple teams.
Modified on by LeslieEkas
Short feedback loops are one of the key benefits to the success of agile because they enable teams to learn fast and adjust. This technique is leveraged in numerous practices used by agile teams including the daily standup, sprint demos, code checkin, build and validation cycles, pair programming, and continuous delivery. One of the key benefits that convinced me to try agile was its claim to deliver greater value with higher quality. After I had experimented with agile for a while, I started to understand just how critical short feedback loops are to achieve these goals.
Short feedback loops enable you to learn fast so that you can adjust while the costs are low. It has been well understood in software development that the cost to fix a defect increases and in many cases increases dramatically the longer you wait to fix it. Some of the reasons are that more code may have been added making the defect more complex to fix, the new code requires additional testing and fixing, and by the time you get to the fix, you may have lost familiarity with the code in question. To combat this issue, it is critical to find defects soon after the code is checked in. One short feedback loop used to combat this is to automatically test the code through a series of progressive test gates. Additionally if the code is checked in frequently (another short feedback loop) developers get quick feedback on quality.
Another manifestation of short feedback loops is the daily standup which enables teams to identify critical blockers and get help to get them fixed before the next meeting. Someone has a problem, someone jumps into help fix it. Shorten the time to fix a problem; reduce the cost.
To ensure that agile teams are meeting the needs of their customers, they demo their new work at the end of each sprint to get timely feedback. This version of a short feedback loop is fairly well known to agile teams but it may be surprising how few teams actually do these with their end users. These demos give the product users ongoing updates on how the new code is progressing and the opportunity to provide feedback. This kind of feedback is like bug fixing, the sooner it is applied the more cost effective it is. Going a step further, releasing functionality frequently enables users to get traction and provide feedback before the functionality is complete. Customers have to be willing to experiment and respond but the win for them is that they do get an active voice in getting the value they require.
As teams continue their agile adoption, it is useful to remember why we adopt various techniques to make sure that we get the value promised. To deliver higher value with better quality we use short feedback loops so that we learn fast and adjust.
Modified on by ScottWill
In my previous post I mentioned how to use end-of-iteration reflection meetings to determine what a team should focus on for improvement in the next iteration. In this post I want to briefly cover two different ways that a team can tackle those improvement actions.
In the first – and simplest – case, let’s say a team needs to fix a problem with their automation framework that is causing some instability. So far, the team has just addressed the immediate symptoms in order to get the automation back up and running, but there’s a sense within the team that the problem runs deeper and needs some focused effort. In this case, the team needs to set aside some dedicated time during the next iteration in order to solve this problem at its root so that it doesn’t keep coming back time and time again, and continually costing the team. Some teams I’ve worked with have simply written a user story and put it on their backlog of user stories to ensure that the dedicated time actually occurs. In this case, the story goes to the very top of the backlog – the team addresses it at the outset of the next iteration (since it’s now #1), fixes their automation problem, and only then starts working on the next story on their backlog. Whether you choose to write a user story or not is up to you – the KEY is that you set aside time to handle smaller issues.
The second case involves larger problems – problems that will take time to solve and that can be quite complex. A simple example of this may be that the automation framework that the team has been using for years may no longer be supported, and now the team has to move to a brand new automation framework. This undertaking isn’t going to be able to be handled in a day or two – even with the whole team focused on helping. Since there’s always pressure to get new features and functionality out the door as quickly as possible, the team most likely isn’t going to be able to hit the “pause button” for four weeks while they switch over to the new framework. What we suggest here is a bit of a compromise: create a small team of automation folks and dedicate them 100% of the time to moving the current automation to the new automation framework. The remaining team members continue to focus on new feature work. The important thing with this suggestion is that you’re getting your new automation framework implemented while still getting new feature work completed (albeit at a somewhat slower pace) – but you’re doing so without having engineers multitask across different sets of responsibilities. This approach honors the lean principle of working on one thing at a time.
Just to recap – if your tackling a small improvement action, dedicate time. If it’s a larger improvement action, dedicate a team.
As always, please feel free to respond with any additional advice, insights, experiences, and/or questions that you may have. Thanks!
Modified on by ScottWill
A while ago I started working with a team that had stopped having “standup” meetings altogether. Initially, the team started with the typical daily team meetings. After a little while they moved from having daily meetings to having them only three times a week. Subsequently they went to just once a week. When I asked why they had decreased the frequency of their meetings, and then ultimately stopped having them altogether, I was told that no one thought they were very useful and some of the team members had already stopped attending.
At one level, I applauded this team – they had taken one of the Lean Principles to heart, that of “Eliminating Waste.” Their attempts at having daily standup meetings weren’t providing any value, so they just stopped having them. However, at another level, I faulted this team. They held daily standup meetings because that’s what they thought they were supposed to do since they were now calling themselves “agile.” In essence, they had adopted a practice without understanding why they were adopting it, nor did they understand what benefit the practice was meant to provide.
What I have found in my years of coaching teams is that when teams reduce the frequency of the daily team meetings (or eliminate them altogether) it’s usually because the meeting has become just a status meeting. And, seriously, who wants to spend time every day reporting status as well as listening to others report status…? What you typically hear in such meetings are things like, “I’m doing the same thing today as I did yesterday,” “I’m still working on my code,” “I’m still finding defects,” and so on. Ugghhhh – what a waste.
So, if it’s not to report status, then what’s the purpose of the daily standup meeting? It’s meant to be a coordination and communication meeting for the team. And this type of meeting is very important. However, there are a couple of other things to cover first before I can show how the daily standup will be valuable – instead of daily waste of time.
Leslie and I recommend that, as much as possible, a team should be working together on one user story at a time. Additionally, the work items that team members tackle as part of implementing a user story (typically called “tasks”) should be small in size (a day or two at most). This means that small amounts of needed design, coding, testing, user documentation, automation, and so forth are being completed on a daily basis. For example, a developer could complete a coding task and, as soon as the build finishes, a tester can start running tests against that code. Thus there is a lot of “parallelization” taking place every day within the team. Perhaps you can now begin to see how important regular (daily) team communication is in such an environment. Conversely, you can see how the daily team meeting devolves quickly into a status meeting if everyone is working on their own thing and there’s no shared goal for the team.
By working together on one user story at a time, and using small tasks to accomplish work, the daily team meeting becomes a meeting that you don’t want to miss because you’ll likely miss something critical to the work the team is focused on.
Modified on by LeslieEkas
One of the primary reasons that agile teams are “more productive” is that they work together closely to complete small batches of work frequently and continuously. The better the team is at working together, the better their productivity. However, teams struggle to improve their ability to work together, and so this becomes one of the most significant barriers to real agile success.
If you think about how work goes in a typical waterfall project, usually the first thing that happens is that the team decides what they are going to do and then very quickly they split into separate sub-teams to do the work. Generally the team does most of its coordinated work at the end of the project when they have to make it all work. This is the "hockey stick" effect of waterfall. From my days in waterfall I remember long hours, nights, and weekends working through problems with the rest of team. In fact I remember reconnecting with people that I had not worked closely with since the last “end of project march.”
Agile breaks this pattern by working closely together from the beginning of the project. The “end of project” style of coordinated team work in waterfall happens throughout every iteration. This is what makes agile so productive. However, “getting there” can be hard because working where your domain knowledge and skills are the strongest is where you want to work and where you know you will be the most productive.
As the software industry has progressed, software projects have become larger and more complex. With size and complexity, specialization typically follows. We have been encouraged to specialize in order to capitalize on our personal strengths and then use those strengths to produce better product capabilities. Specialized skills are critical so that we build the right solutions. However, learning new skills and increasing your technical breadth is also important. To make an agile team more productive, team members needs to be willing to broaden their skills so that they can help the rest of team get to “Done!” in addition to completing their own work.
This does not mean you have to become an expert at everything or even offer your help when it is not needed. When I was in school getting my Computer Science degree, our professors told us that “You are not a <insert favorite software language> developer, you are a software engineer.” We have to remind ourselves that, as engineers, we need to continue to expand our skills and knowledge, and be willing to try any job that needs attention. If everyone on the team assumes this attitude, the team will become more productive.
Here is the analogy that I think of when I am trying to explain this behavior. In the movie Apollo 13, after the initial oxygen explosion happens and disaster ensues, the mission commander asks that his team leaders to call in everyone on their teams to help figure out how to get the crew safely back to Earth. In the movie, teams that have not worked together are given hard problems to solve fast -- and they do solve them. This is the way very productive agile teams work together throughout the project.
Modified on by ScottWill
First of all we would like to wish everyone a Happy New Year! We trust that this year will be full of good challenges and significant achievements for each of you!
Regarding metrics, if it's one thing that engineers love, it's numbers... And if it's one thing that managers love, it's status. Put the two together and oftentimes you have teams that track tons of metrics across all facets of their projects.
While it may give the impression of being really thorough, and providing all sorts of deep insights, if you find yourself in an organization that tracks lots and lots of metrics, then I would encourage you to take a step back and limit the focus to just what's really important.
One of the principles of the Agile Manifesto reads, "Working software is the primary measure of progress." If you stop and think about it, that principle makes perfect sense. Customers aren't going to buy untested code and they're not going to be too happy if they buy something that falls down broken all the time because major defects haven't been fixed. All other metrics should pale in comparison to the one metric of having working software. Putting focus on this one metric will drive many of the benefits that agile promises -- three of which I'll touch on here.
First, focusing primarily on having working software provides a shared, common goal for the organization. This means that no one on the team gets any credit for his or her individual efforts which, in turn, provides plenty of motivation for helping each other out so that the team can take credit for having working software. A lot of the old "us vs. them" mentality of waterfall days is eliminated when focus is placed on working software as the primary measure of progress.
Next, having the focus on working software means that teams will actually achieve working software much earlier in a project than was typical with waterfall projects. Having working software provides plenty of opportunities to involve customers earlier in the project since customers can actually see demos of the functionality while it is being implemented and can even download it and test-drive it in their own environments. Getting customer feedback early is a huge benefit, especially if customers tell you you're going down the wrong path since you'll be able to make mid-course corrections prior to releasing the product.
Finally, having working software enables teams to move into the DevOps space where automation takes on an even more significant role, where releases are more frequent (up to multiple times a day for some Software-as-a-Service offerings), and where opportunities for doing things like "A/B" testing can be pursued. None of this is possible without having working software.
To conclude, if you agree that focusing on working software as the primary measure of project progress makes sense, but you're not quite sure how to ditch many of the metrics you may be currently tracking, I'll leave you with this analogy that Leslie uses with teams when dealing with this very issue. Think of cleaning out your closet -- you pull everything out and then put back only those things you wish to keep. Everything else is either thrown away or donated to charity. So, start with a "clean slate," put working software at the top of the list, and then add only those additional metrics that are absolutely necessary to ensure project success. Tracking anything else beyond just what's absolutely necessary should be considered a waste.
We would be interested in your thoughts and comments, especially if you've already made the transition to tracking working software as your primary metric. Thank you!
Modified on by ScottWill
A couple of years ago a well-known franchise experienced a significant computer outage that affected hundreds of their stores throughout the U.S. The impact of the outage lasted for nearly a day, and the problem made the news headlines all over the place. Obviously these are the kinds of problems that businesses don’t want to have happen to them. Loss of sales, unhappy customers, and bad press don’t make for a good day…
With that in mind, let’s assume that it had been years since this franchise had experienced any kind of outage. Do you think customers (as well as shareholders) would have been happy to hear the company’s executives say something like, “But it’s been years since we’ve had any kind outage!” Probably not… Was anyone focused on how long it had been since the last outage, or were folks more interested in the “here and now?” Given the fact that the outage made the headlines, it’s obvious that the lengthy delay in getting back to normal was the primary concern.
Now, let’s look at a hypothetical situation where a company experiences several computer outages every day, but the length of each outage is only one second (or less). Would anyone even notice? Probably not… Because the recovery time was so fast, the only folks who would likely even be aware of any of the outages would be the operations folks, and only then because they were analyzing the logs from the monitoring tools in place.
Hopefully you can see where I’m going with this – a company that experiences a failure only once every couple of years (i.e. having a very good Mean Time to Failure), but one that takes a day or more to recover from an outage (i.e., having a very poor Mean Time to Recovery), is likely to have more negative results than a company that has a very poor MTTF but that has an extremely good MTTR.
So, just to be clear, I’m not suggesting that MTTF should be ignored – referring to my second example, I’d really like to know why outages are occurring so frequently, and then work to reduce the number of outages (even if they do only last a second or so). What I am suggesting is that MTTR should be one of your “front and center” metrics. The faster you can recover from an outage, the less noticeable the outage will be and, therefore, the more negligible the impact.
If you haven’t started measuring MTTR for your offering, please allow me to suggest that you need to begin doing so ASAP. And, once you have MTTR measurements in place, then begin working to improve them (no matter how good they may be right now).
Modified on by ScottWill
One of the things that has been extremely popular in software organizations for a long time is to count the number of defects that have been found via testing. I propose that teams no longer do this for two reasons.
First, one of the lines of thinking behind counting defects is that it is somehow a measure of quality. If we were running an assembly line in a manufacturing plant, and the assembly line didn’t change from one week to the next, but the number of defects increased, we would know there was a quality problem somewhere – something on the assembly line was likely broken. Despite some similarities, software development is not an assembly line – unlike an assembly line, every line of code that is written and tested has never been written or tested before, so expecting defect counts to be an indicator of quality doesn’t correlate. If a team found 25 defects last week, and 50 this week, what does that tell us? Is the code quality really getting worse, or did the team just do a lot more testing? If so, did the tests executed reflect real-world usage, or were the tests all edge-cases? Did the team deploy the code into a new environment that had never been used before? I’m sure you can come up with many more scenarios… Anyway, the possible reasons for the higher number of defects this week are almost boundless, and the time spent trying to determine why the variation occurred would be better used to: work more with customers to better understand their usage patterns and particular needs; create more needed functionality; improve their processes further; cross-train team members; adopt a new tool; etc., etc., etc. All of which leads to my second point…
Agile software development has its foundations in Lean Thinking, and one of the Lean principles is to eliminate waste. Does counting defects, and spending time trying to figure out what causes variations in the numbers of defects from one time period to the next, contribute directly to the success of the project? If not, then the time spent doing so should be viewed as a waste – time that could be better spent doing more important work.
In conclusion I’d like to leave you with two thoughts regarding defects: first, when defects are found, they should be fixed immediately – period. Don’t allow a backlog of defects to accrue. If it does make sense to do some root-cause analysis to determine why a particular defect occurred, then that’s fine – do so when it makes sense to do so, but it likely does NOT make sense to do so for the vast majority of the defects found. And the second point is that a mature, Agile team should be able to have “difficult” conversations when needed: “Hey Scott, I’ve noticed that I’m finding a lot of defects in your code this week – is there anything that’s distracting you, or anything I can help you with?” Instead of taking umbrage at such comments, I should be thankful that my team is willing to raise the issue and have the discussion.
So, the next time you’re asked to track the number of defects found, ask “Why…?” The answer will likely shed light on ways to eliminate waste and help overcome the “That’s the way we’ve always done it!” mentality, as well as foster a relentless, continuous improvement mindset.
As always, thoughts, comments, and questions are most welcome! Thank you!