Blog


Comparing Opportunities in an Agile Portfolio

Agile approaches such as Scrum are excellent for successfully delivering great complex products but how do we know what products to develop and when? 

Take a look at the Agile Planning Onion, which I first saw many years ago in Mike Cohn’s Agile Estimating and Planning book:

In this article I want to explore how we can use agile techniques to help us make the comparisons required to make good portfolio decisions about what projects to start, stop or even pause regardless of what agile approach we prefer.

Agile Portfolio Management

There is a lot more to agile portfolio management than comparing projects.  If you'd like a more in depth view on the topic I'd recommend reading “Agile Portfolio Management” by Jochen Krebs as a good starting point - however, in this article I'll focus primarily on comparing projects, with the assumption that an experience team would be doing more than just comparing.

What Are We Comparing?

Whether we call what we’re developing projects, products, opportunities, features, epics or just big user stories really doesn’t matter to me. Here, I’ll refer to something we’ve not started as an opportunity and something that is in already in progress as an active project.

We can compare metrics such as cost, benefit, duration, current chance of success, strategic alignment, project type and active RAG (Red, Amber Green) status to help us make good decisions.

Who Is Doing the Comparing?

All the benefits associated with agile teams such as self-organisation and continual improvement can be gained by creating small and stable teams to analyse and compare our opportunities and active projects. We want these people to become really good at this kind of work, we might even want to call them a discovery team.

Hint: Jeff Patton wrote a great book called User Story Mapping, which includes really good practical advice, tools and techniques for building shared understanding about development opportunities.

How Are We Comparing?

The Discovery Team can use short, two-week or even one week iterations to gather just enough information to be able to perform the quick comparisons that we need. They will rely on multiple rich interactions with people from around the organisation and maybe even beyond - this can include customers, users and other stakeholders in order to build a good shared understanding of the opportunity.

Discovery Iteration Reviews

As part of the Discovery Iteration process they can hold iteration reviews where stakeholders can be shown what progress has been made towards building that shared understanding. These reviews give the team the opportunity to do three things:

Trash Opportunities - we have learned enough to know that we don’t want to carry on with the opportunity. Trashing things that would otherwise burn resource for little or no benefit early should be seen as a fantastic result. Present Estimates – we have built enough shared understanding to relatively estimate the opportunity’s metrics. Iterate Again - we haven’t built enough shared understanding to allow us to trash or estimate, so we iterate again. It’s All Relative

I’m one of those people who finds it useful to relatively estimate user stories using story points.  It allows me to quickly compare one story against another in terms of overall size, which is exactly what we’re looking to do with each of our opportunity metrics.

And just like estimating user stories, we are not looking for precision; we are looking to for a useful level of information such as “Opportunity A costs about twice as much as Opportunity B”.

We can play Planning Poker and generate fierce debate and relatively estimate each metric against other opportunities or projects that The Discovery Team understands really well, which is one of the advantages of a small stable team.

Visualising the Comparisons

We should now have some really valuable information that can be used to make good portfolio decisions. It’s important to document this information to avoid it being lost or forgotten, so we might want to create a table like the one below.

Doing this is practical but it’s not very visual. Krebs suggests the alternative of using a simple quadrant diagram, which I’ve adapted a little to include a few extra dimensions and to accommodate our relative estimates for each metric.  So we can plot our data like so:

Here’s how to use the diagram:

The shape identifies the type of opportunity or project. For our example, a circle represents something our organisation is choosing to do and a triangle represents a mandatory piece of work required to comply with a regulatory body.  The size of the outer shape is the relative benefits that our organisation hopes to harvest by developing the solution. The size of the inner shape is the relative cost of developing the solution. If there is only one shape the cost of the development is equal to or higher than the expected benefits. The letter in the centre identifies the opportunity or project and can be colour coded to represent a RAG status for active projects. A solid line is an active project and a dashed line is an opportunity. The colour of the shape represents a certain strategy that the opportunity or project is aligned to. All metrics are relatively represented by either the size of the shapes or the positon along either axis. The above diagram is for demonstration purposes only and is not exactly to scale. Drawing Conclusions

Using this diagram we can see, at glance, that we have four active projects and four opportunities that are a combination of optional and mandatory projects.   The portfolio seems fairly well balanced across our strategic alignment and also across the four quadrants. What other useful conclusions can we draw?

A is relatively inexpensive piece of work that has a good chance of successfully delivering positive benefits; which is supported by its green RAG status. B is a hugely expensive, long running piece and has a very low chance of success, which is probably reflected in its RAG status of red. Perhaps we should be looking at stopping it. C is a relatively inexpensive piece of work but its single shape indicates that we don’t expect to harvest any significant benefit from doing it as it is likely to run for a relatively high duration. Its RAG status is amber despite its high chance of success.  We should definitely take a closer look at this.  D is a fairly inexpensive, short, mandatory project that will be of benefit. However, its RAG is red; perhaps this is linked to its low chance of success.  We have no choice but to deliver this project, so perhaps should investigate what can be done to increase the chance of success.  E is inexpensive and short with a great chance of successfully delivering huge benefits. We should look to get this started soon, potentially by freeing up resources from Project B.  F costs a bit more, which is reflected in its long duration but it does have a decent chance of success of delivering positive benefits. It’s worth a closer look but it may need to wait.  G won’t cost that much and will yield modest benefits. Its lower chance of a success is a concern but at that cost it might be worth taking the risk.  H is another mandatory opportunity, which is more expensive and had a very low chance of success of yielding estimated benefits. However, it needs to be done, so perhaps we look into why the chance of success is so low and try and address those concerns before staring it.

The combination of the relatively estimates metrics and the diagram gives us useful visual clues that we can use to aid our portfolio conversations and decisions making process.  You can change, add or remove any of the metrics I’ve used as you feel appropriate for your own situation.

Please share your thoughts using the comments section below.

We Can’t Maintain a Sustainable Pace with Many Small Projects

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I prefer to think about this agile principle as: “Anyone who contributes to the success of the product should be able to maintain a constant pace indefinitely.”

The main two groups that I like to bring under the umbrella of “anyone” are subject matter experts and senior stakeholders. These groups are usually outside the development team, but need to be available for frequent conversations with the product owner and to provide timeous feedback at iteration reviews.

We often find that multiple projects are suffering because “anyone” is frequently unavailable, usually due to other priorities. 

In this post, I will highlight how starting too many projects can put an unreasonable strain on those inside and outside of the development team and lower the team’s chances of successfully delivering products.

We Often Need to Split Resources

Obviously, every project that we start needs resources and those are usually limited, meaning that new projects need to be resourced by allocating portions of people’s time.  Suppose we split someone’s time equally across three projects; that means that the person in question will be unable to work on two out of the three projects around 66 percent of the time, or 3.3 days per week.

Being unavailable for that much time is undoubtedly going to have a negative impact on velocity and quality. We can incur up to a 40 percent penalty in productivity associated with multitasking on complex tasks. A quick search on the internet shows just how widely accepted this argument is.

Our Teams Can’t Improve

Another downside of splitting resource and creating teams specifically around projects is that we lose the chance for our teams to continually improve via building relationships, knowing one another’s strengths and weaknesses and solving complex problems together.

According to Robert C. Martin in his book “The Clean Coder”, “Banks and insurance companies tried to form teams around projects. This is a foolish approach. The teams simply cannot gel.”  

He claims that we can’t even call these creations teams and that there is no such thing as half or quarter of a person and suggests that it is better to assign multiple projects to an established gelled team, who will work together to figure out the best way to get them done.

We Hinder Our Chances of Essential Engagement

Users, sponsors, subject matter experts and senior stakeholders all have jobs to do outside of our projects. Furthermore, the same people tend to be in demand for each small project that we start due to expertise or seniority. This is especially true if those smaller projects are related to a common product or strategic goal.

The more projects we start, the more demands we are making of these people, meaning that they can no longer work at a constant pace and can no longer be available for teams when required. Even when they are willing to work lots of overtime, they can’t be in two places at one time. So, through no fault of their own, they become huge blockers for all projects that depend on them. 

We Introduce Avoidable Dependencies

If we create lots of small projects that contribute to a common product or strategy, we will introduce the overhead of managing dependencies that are avoidable simply by either creating larger projects or allocating projects to an existing gelled team. It’s better to eliminate rather than manage dependencies wherever possible. 

We Risk Perpetual Change

We need to be careful to ensure that the projects we are running concurrently are not delivering changes to the same users. The success of our products will ultimately be decided by our users, so we don’t want to place them in a perpetual state of change, making it impossible for them to get their jobs done without working sustained longer hours.

We should be more concerned with significant process or cultural change here, rather than the well-managed continuous delivery of small software updates, which many users welcome.

We Cause Excessive Overtime

We have seen that starting many projects can put strain on those inside and outside of the development team. The diagram below shows the vicious cycle that we can become trapped in as the negative symptoms of sustained excessive overtime lower our quality, morale and productivity, which in turn leads to more negative symptoms. Thus, the cycle is begun anew.

Choosing the Best Option When Starting Projects

Imagine for a minute that we’re property developers and have purchased two properties that we want on the rental market within 12 months. Each requires six months of dedicated renovation at a cost of $2,000. Property A will receive $2,000 per month in rent compared to the $1,500 Property B will receive. We can choose from three seemingly sensible approaches. The table below shows each approach and how it may broadly impact our profit.

 

Property A

Property B

Total

Profit (24 months)

Simultaneous: Team works on both properties an equal amount within each iteration

Time

8.4

8.4

16.8

- $8400

Cost

$16,800

$16,800

$33,600

Income

$14,400

$10,800

$25,200

Alternate Iterations: Team focuses on each property for an entire iteration alternatively

Time

6.9

6,9

13.8

$8.100

Cost

$13,800

$13,800

$27,600

Income

$20,400

$15,300

$35,700

Linear: Team finishes Property A before starting on Property B

Time

6

6

12

$30,000

Cost

$12,000

$12,000

$24,000

Income

$36,000

$18,000

$54,000


In his book “Agile Portfolio Management,” Jochen Krebs states that we could safely apply a 40 percent penalty to the “simultaneous” approach and a 15 percent penalty to the “alternate” approach, which increases our costs while reducing our income period.

Over a period of 24 months:

The “simultaneous” option is by far the worst and actually results in a loss of $8,400. The “alternate” option is considerably better and results in a profit of $8,100. The “linear” option is by far the best and yields a profit of $30,000. As we prioritize Property A over Property B in terms of pure business value, we finish on time and on budget. Even if we reject the switching penalties completely, this option remains most profitable because we can begin harvesting income from our most profitable property after six months instead of 12.

Kreb suggests that in reality the switching penalties can be much higher on complex projects and increase as the number of active projects grows, which makes the argument for the linear approach even more compelling.

Try to Be Professional

In the previous section, we saw that prioritizing and focusing based on business value offers an earlier and higher return on investment (ROI). It is the professional thing to do, so we need to at least try to be professional when making these decisions.

I say “try” because being a professional is difficult and often requires us to say no to our managers. However, just because it is difficult doesn’t mean we shouldn’t do it. Again in “The Clean Coder,” Robert C Martin agrees:

“Slaves are not allowed to say no, and laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no.”

In my next post, I will demonstrate how to use a balanced agile portfolio, so that making professional decisions and saying no to good managers becomes easier.

In the meantime, feel free to share your thoughts on having many active small projects in the comments section below.

Agile Can Succeed Outside of Software but Transitioning Isn't Easy

Like many other proponents of agile, I hear myself regularly stating that agile can be successfully applied outside of the software industry.  While I firmly believe this to be true, I also believe that it can be significantly more challenging to be successful with agile in organisations outside of software and IT. In this post I want to highlight some of the reasons why. 

A Non-Software Development Scenario 

Many organisations have problems with their data quality. Their data stores usually consist of successful or unsuccessful software implementations; they have a massive over-reliance on uncontrolled spreadsheets, manual files and, of course, all the data stored inside the heads of veteran employees.

Because of this, it is not uncommon for such a business to buy a piece of software and then realise that a large data cleansing project is required before it can be populated and used with confidence.

The new system will be used differently by everyone in the business from management to operational field staff.  Each data record would require work to done by various specialist functional areas across the business to ensure it is accurate.

I believe Scrum fits perfectly with this type of problem since each vertical sliced requirement can be a completed data record and, as said requirements are completed, they can be regularly integrated into the new system and accessed by users.

Agile Remains Tightly Coupled to Software Development

The first problem we may face is that it is simply more difficult for non-software people to learn and relate to agile. After all, books about agile are full of software development jargon and have full chapters dedicated to topics such as Extreme Programming, Test Driven Development and Continuous Integration. The same is true of most agile websites, blogs and training courses. 

Recently, the word “software” has been replaced with “product,” but all the available examples continue to be focused on software, which makes the word “product” somewhat of an empty gesture – in other words, a rose by any other name is still a rose. 

Thus, it is understandable why some people think that agile only works for software development, and continue to be sceptical when we suggest they read a book or take an online course that only talks about software.

Barriers to Ensuring Change is Driven Bottom-Up and Top-Down

The problem described in the previous section also makes it much more difficult for non-software organisations to achieve the correct mix of bottom-up and top-down support that is required to successfully drive change. 

In the software industry, the development team at the bottom often take it upon themselves to implement agile and then use the positive results of that decision to gain support from influential senior management at the top. Or, senior managers see the results that other companies are getting with agile and drive the change from the top with a goal of getting complete buy-in from below.

Both cases happen because it is impossible to be a professional in the software industry and be unaware of agile. This is not true of other industries, and sometimes we find ourselves having to implement agile methodologies from the middle, which is far more challenging.

Applying the Concept of DevOps

DevOps is the term used to refer to a set of practices that emphasize the collaboration and communication of software development teams and IT Infrastructure with a view to automate the process of software delivery and infrastructure changes. DevOps also aims to establish a culture where quality software products can be released rapidly, frequently and reliably.

We increase our chance of success by having good DevOps, so it is a fair assumption that other industries will need something similar to release their products in the same manner. Sourcing or creating a DevOps for a specific non-software industry is significantly more difficult, especially if there are real operational or cultural changes required when releasing products.

Creating Cross Functional Development Teams

Good agile software teams are cross-functional, meaning that they possess all the necessary skills to get vertical slices of the product done. This is a relatively simple endeavour because the resource is usually under the umbrella of Software Development or IT.

In other industries, however, it can be much more difficult to create a cross-functional team since members can come from highly independent functional areas. For example, a data record may require work from various technical departments as well as the HR, Finance and Health and Safety departments. Each area has its own management structure, political agenda and mini-culture, which makes building truly cross functional teams much more challenging.

Defining Quality

In software development, the idea of quality assurance is very well defined and includes aspects such as whether or not the code is well written, has been peer reviewed, checked into version control, has automated test coverage, has been manually tested and has earned the approval of the Product Owner. Of course, these things usually become items on a checklist called the “definition of done” that has to be true in order for the requirement to be considered complete.

When our product is not software, we need to define what quality means and create our own definition of done.

For instance, on a large manual data cleansing project, what would quality represent?  What would the definition of done be?

Of course, we would need more information on the type of data such as the complexity involved in arriving at the values to be entered, dependencies and whether our system can help validate in anyway. 

Try to think about a non-software product and what its definition of done would be. It is not easy, and it is unlikely you’ll find one as easily as a software professional would.

The Starting Line is Further Back

I may be biased, but in my experience, the software industry is amongst the more mature in regards to general project or product management. It is unusual to find that there is no formal approach in place, and there is normally a good general awareness of prioritisation, scope, benefits realisation and resource and asset profiling.

Many traditional software teams realise on their own that no matter how well they adhere to so called traditional “best practices,” they continue to have no or limited success. This creates a healthy mix of bottom-up and top-down motivation to transition to agile, not least because of the vast array of supporting material and success stories that are widely available specifically for the software industry.

Not all industries are as mature in their project management approach and tend to have little or no understanding of managing a balanced portfolio. Because of this, I have seen coaching conversations similar to this:

Agile Coach: “Perhaps consider stopping this task, it is a huge productivity leak.”

A Manager: “Yeah, in an ideal word I would, but we need huge productivity leaks here.”

In this situation, people are asking how agile can be changed to fit with the organisation, instead of asking how the organisation can change to fit with agile. 

And, as mentioned earlier, the supporting material and success stories specifically for their industry don’t exist or are much harder to find. In these cases, our challenge is much greater than transitioning a good traditional software company to agile.

Please Help

I’ve only had a chance to raise some of the additional challenges that I think exist when transitioning a non-software organisation to agile in this post, and I’m very aware that I haven’t offered any solutions. However, I will follow up with some useful advice soon.

I certainly don’t have all the answers for all challenges in all industries, so I would love to generate some useful discussion and ideas here. Feel free to share your thoughts in the comments section below, and let me know what would help you feel confident about the success of agile in your industry or organisation.

 

 

Size Matters in Agile

Recently, I have been working with organisations that have made things difficult for themselves by having teams that are too big, user stories that are too small or a combination of both.

While there are many differing opinions on the ideal size of either one of those things, my own preferences (on average) are the following:

A good agile team is seven, plus or minus two A good story size is about two days to one week’s effort A good task is between two and 16 hours

So, a team that is too big is:

10 or more people

And a story that is too small is:

Around one day’s effort or less as a rule of thumb

Next, let’s look at some of the issues that we might encounter if we consistently work with teams that are overly big and/or user stories that are very small.

When the Team Is Too Big

The effectiveness of team communication decreases when the team is too large. There has been lots of research in this area that can give a lot more detail than this post, so here I just want to give a few examples, especially around ceremonies.

Many people suffer, to some extent, from Glossophobia, which is a fear of public speaking. If we have big teams, our ceremonies can feel like public speaking, especially if there are also people from outside the team present.  

Some who will have very good points to contribute may not and we will lose their valuable input. In agile, we value face-to-face communication because it is very effective, so we shouldn’t create situations where people are anxious about speaking.

Another thing to consider is that all ceremonies will take longer or become rushed as teams become bigger. I have witnessed one team that was so big that their daily scrum took over 30 minutes. The Scrum Master’s answer to this was to limit everyone to essentially saying: “Yesterday I worked on Story X; today, I will continue to work on Story X.”

Anyone attempting to talk about anything else at all was advised to have a discussion later and all effective communication was lost.

Likewise, estimating and planning sessions, retrospectives and reviews are similarly impacted.

When User Stories Are Too Small

In his book “User Stories Applied,” Mike Cohn suggests that we should use the INVEST acronym to help us write good user stories. The principle is that stories should be:

Independent Negotiable Valuable Estimable Small Testable

Let’s take each one and examine some of the challenges that we might face if we try to follow Mike’s guidance when we have very small stories.

If our stories are too small, it can be difficult for them to be independent, which leads to planning and prioritization problems. In fact, having too many dependencies makes it difficult to adhere to the majority of the other principles, because to satisfy them, we would need to consider the full dependency chain.

For example, if the related stories are not yet developed, is the user story still as valuable? Can it be estimated independently? Can it be effectively tested in isolation?  

Very small stories are difficult to negotiate as they deal in the lower level detail. The acceptance criteria are no longer reminding us to have future conversations, but instead make us feel like no conversation is required. We miss a chance to have conversations and hear other viewpoints that could lead to a higher quality product.

It is not unfeasible that a small story can be very valuable by itself, but often overly small stories are of little value until their related stories are done.

I do concede that we should get more accurate estimates with smaller stories, but with an increased number of stories that contain lots of detail, those estimating sessions will be onerous and I would question if the increased accuracy would be worth this extra effort. When we estimate using story points, we are not looking for precision, just an idea of relative size.

Good user stories should be small but they shouldn’t be micro. They are small enough to be done in a sprint, but not so small that they can be done in a few hours.  

As previously mentioned, it can become difficult to make small interdependent stories testable and it often seems more efficient for testers to group these together, which suggests they could have been one story to begin with.

It is important to note that I’m not saying that we can never have a very small story, just that it should not be the norm. If we see a user story as normally being two days or more effort, it still leaves us some scope to break those stories down into meaningful tasks in a sprint planning session, discuss them in detail and estimate in hours.

When Teams Are Too Big and User Stories, Too Small

If we have a larger team, which has a larger capacity, we can do lots more small stories. If we double our team size, we will probably just about double the number of stories we aim to do. This directly results in an increased overhead being applied to almost everything we do.

It is fairly easy to imagine how our ceremonies would become even more onerous when we add more and more detailed stories for consideration. However, there are some other key areas that are now less effective:

Story boards are too busy to communicate effectively Grooming the product backlog is more difficult due to even more dependencies Re-planning or modelling are even more difficult

If we favour the technique of capacity planning (I think we should), we will find that it is very difficult to break small stories into meaningful tasks as they are task size already. What’s more, you would probably have hundreds of them. These things taken together usually means that the technique is unworkable.

In Summary

I continue to work with teams who struggle with these issues in one way or another. While I don’t think we need hard-and-fast rules for every user story, I do think we should be watchful for what could be described as an anti-patterns developing in our organisations or teams.

I would love to hear what you think and if you have any further examples where team or user story size matters; please share in the comments below.

Have You Checked in Yet?

Many teams acknowledge that it is best practice to “check in” code to a shared code repository, and developers may check in multiple times when delivering a single user story. Knowledge of whether a developer has checked in or not is, in itself, not very useful to us, so as Scrum Masters or agile project managers, what are we really asking?

We are, of course, asking for a progress update and in most cases simply asking: “Have you finished the story or task you have been working on?”

In this post, I would like to look at a couple of common scenarios where asking this type of question regularly can have a negative impact on team morale and lead to a reduction in quality, and then suggest what we may do to avoid asking too often.

Scenario 1: We Don’t Know

It may be that the communication within the team is not as effective as it could be, so we are not getting the information that we need. In agile, we can use daily stand-up meetings and team boards to communicate progress.

If this communication is not giving us what we need, it may be tempting to hover round the team asking for updates, but it is probably better to spend time coaching and reinforcing good agile practices that will benefit the team now and in the future.

At the daily stand-up meeting, each team member should aim to give a clear update on the status of their tasks and if they are impeded in any way. While it is important not to see the meeting as merely a status update, it is reasonable to talk about expected progress. Coach the team to give clear and useful information.

Another way to communicate progress is with a task board and burndown. Personally, I prefer to capacity plan in sprint planning meetings so that we can break stories into tasks and estimate in hours.

We can ask the team to update the hours remaining on a particular task each day. If we see that a task has 12 hours left against it at the start of a day, it is usually quite pointless asking if it will be finished by the end of the day.

Consider capacity planning and burndown hours instead of story points during sprints so that we can easily see how much effort is remaining on a particular task. Again, we can coach the team to keep the board up to date with accurate information and look at it when we are checking progress.

A danger here is that our team is doing these things well but we are not, which means we are regularly asking questions that they have already given the answers to. This can lead to people becoming disillusioned with the process and a reduction in team moral.

Communication is two way, and we need to listen properly at the stand-up meeting and take time to understand what the board is telling us. It can be frustrating for someone to be asked if they will be finished today just one hour after they stated that they won’t be, or if they have clearly marked on the board that there was 14 hours remaining on the story.

In both scenarios, the person being asked the question will probably be thinking that we don’t listen to them, we don’t pay attention to the team board or that we would quite like them to work 14 hours today.

Scenario 2: We Do Know but the Team is not Going Fast Enough

In this scenario, we have the information we need to know when a task is likely to be finished, but we would like it to finish before then. We tend to ask this question more when our team is not progressing as fast as we would like, which is contrary to the agile principles of self-organising teams: working at a sustainable pace and delivering quality.  

We need to be careful here, as we are behaving more like traditional project managers and portraying ourselves as the “boss.” If we know that the team has 14 hours remaining on a story and we ask them if they will finish today, we are implying that we will be disappointed if the answer is no.

This can lead to people cutting corners and working unsustainable hours in order to try and keep us happy, both of which will reduce the quality of the work being delivered.

In Summary

I’m not suggesting that it is the end of the world to ever ask for a status update, but would caution asking too regularly. The best agile teams are self-organising, empowered and work at a sustainable pace.

As good Scrum Masters or agile project managers, we should take time to reflect on whether our own behaviours help our teams be the best they can be.