Working in software development means working with a lot of different technically skilled people. Those ‘IT geeks’ are still ranked by the same roles that were applied 20 years ago. Going from junior to senior developers, functional analysts, project managers, system engineers and architects.

Let us look at the last category, the software architects. They carry the responsibility of the IT systems in the organization. Not on a hardware or operational level, but on a design level. Whatever the development teams build must be of the highest quality.

A traditional software architect uses his experience and knowledge to guard these requirements:

• Performance
• Security
• Audit trail
• Technical logging
• Scalability
• Technology stack
• Technical documentation

In most cases this is done by imposing rules and reviewing work. Besides that, most software architects are often involved into the analysis part of a development project as well. They try to make sure as much business scenarios are covered in the analysis phase to make sure the system can handle anything imaginable.

I think you understand that an architect is one of the least popular people in the company. From a business perspective he/she is perceived to be a critical person who always blows up scope and adds extra costs for technical reasons nobody understands. From a developer perspective he/she is perceived to be a bottleneck, always asking for extra information, demanding code to be re-written, approving or rejecting work from his ivory tower.

Like in many other cases this behavior is caused by the system, being the company. When IT is merely a department working on it’s own and hardly interacting with the rest of the organization, their goal is to perfect their own work. Why wouldn’t they? The rest of the company doesn’t understand technology and is always disappointed when things take longer or features turn out to be harder than planned.

Luckily, there is a new breed of software architects rising, the modern software architect. In companies that have chosen the path to embrace technology and use it to their advantage, the traditional IT department is disappearing. Movements like Agile software development are bringing all the different roles in the organization together in their quest to create something valuable.

I’ve seen a software architect is those ecosystems behaving completely different. Instead of focusing on defending the IT department, they are thinking about what’s best for the company.

• How can we deliver a valuable first version quickly so that we can start earning money or beat our competitors?
• How can we know that our software is matching expectations? How do we measure that?
• How can we make our systems scalable? If it is matching expectations, how can we grow it easily?
• How can we release new versions quickly? Is our deployment pipeline up to the task?
• How can we refactor our software easily? Because business is changing quickly, our software needs to be able to follow.
• How can we guarantee quality in such a fast environment where new software is delivered in days?
• How can we let our people work together and share knowledge?

The difference between a modern and traditional software architect is striking! You could say that a modern software architect has an entrepreneurial mindset. This is the logical consequence of integrating into the organization.

From what I’ve noticed, a modern software architect seems more to enjoy work. It’s no longer an endless battle between the organization and IT. It has become a fight for business success. A fight they’re in, all together.

photo credit: svenwerk via photopin cc

As of the Christmas holiday, I decided to stop drinking coffee for a while.  Just to try and prove my genius insight.  And yes, after just a few days, my stomach ache had disappeared miraculously.   But just to make sure that this was not related to the lack of stress during Christmas holiday, I persevered and didn’t touch any espresso, macchiato or Irish coffee.  So I started the new year coffee free, which was harder than I thought.  My body felt like it was having withdrawal symptoms, especially in the mornings when the urge for a cup of freshly brewed java was the biggest.

I remember it well, one day at a client’s office, I had mistakenly ordered a coffee.   Since my parents raised me to be polite and finish everything you order, I drank the coffee.  Oh boy, what a mistake!  Instantaneously, the next day, my stomach ache returned.   From that point on, I decided to quit all together.

After a while, I started to look for alternatives, because I missed a hot drink in the mornings.  So I started to explore the world of Tea, one I had never noticed before.  Is it normal that coffee drinkers don’t know that there are so many varieties and flavors of tea?   Maybe that’s a Belgian thing, but I also didn’t understand the hassle of tea drinkers, with their little bags and steaming hot water.   To me, it looked like too much effort for a cup of mildly flavored water.

Now, I’ve become a regular tea drinker, enjoying  the ritual and flavor of tea.  Nevertheless, I try to keep it to a minimum because tea also contains some caffeine.  So far, I’ve got rid of my stomach problems, and discovered a whole new world of tea.  I’m not a doctor, so if you try this yourself, don’t sue me for any physical of mental diseases you might develop!

You might ask yourself, what does this have to do with Agile or Kanban?  Well nothing really, I’m going to blog more often about other topics, tea related or not!

photo credits: Kuzeytac (will be back soon) Renée S. daniellemharms cc

One team I’m coaching is in a stage where the project is almost finished.  Typically, retrospectives feel different in this stage.  There is not much room left to benefit from local improvements because development is finishing, the release train is gaining speed and people are starting to move to other projects.

At this point in time, I believed it was time to critically review our current way of working by comparing it to our ideal state.  So I invented Vision Poker!

• First of all, I printed the mind map of our ideal state on an A3 piece of paper and placed it in the middle of our meeting room table.
• Then I gave each participant 4 poker chips.
• After that, we briefly reviewed our ideal state, to make sure everybody understood it the same way.
• Then I gave the team the assignment to “Bet your poker chips on the categories of our ideal state of which you think we’re doing great.  You can put all your chips on one category, or distribute them amongst several.”

This led to the following result:

Then we looked at the categories that contained the least amount of chips and started to discuss them, one at a time.  I facilitated the discussion and recorded what was said.  When discussions stopped, I helped the team to write down actions to improve the stuff that was recorded on a flip chart.

In a 1 hour retrospective, we were able to discuss 4 categories and distill a list of 3 concrete action points.  Maybe that doesn’t seem much, but remember that this team had been working together for 2 years and made a lot of improvements over this period.

Using the poker chips and the betting metaphor made the entire retrospective more fun.  I like to believe that if you ask people to bet on where the team is doing great, they will be more honest because money is at stake (even if it is only fictional).  Either way, it was a fun and efficient way to make a selection in possible topics to discuss during the meeting.  I plan to use my poker chips more often in exercises.  Maybe next time, I’ll use some dices or a wheel of fortune.

3. Cost control

The third controlling process of PMBOK is cost control.  It’s goal is to control the changes that influence the cost baseline.

There are 4 inputs that are used in cost control:

• The cost baseline
• Performance reports
• Change requests
• Cost management plan

As outputs we usually see things like:

• Revised cost estimates
• Budget updates
• Corrective actions
• Estimate at completion
• Lessons learned

Let me try to translate this into agile terminology.

Cost is often an important constraint in an agile project as well.  Not often do we have the luxury of swimming in a pool of money.  Even if we did, as a business owner, we would still like to get as much value out of our investment.  That’s why most projects are estimated and budgeted.

What would be the input of your ‘agile’ cost control?

• The cost baseline = your calculated budget based on estimated or measured sprint velocity, often in the form of a cost burn-up chart.
• Performance reports = the timesheets and invoices of previous sprints
• Change requests = the evolution of your product backlog
• Cost management plan = not prescribed in agile, but generally a sound project management practice.  Determine at the start how you will treat cost variances.

What would be the output?

• Revised cost estimates = an updated release cost burn-up with trend lines
• Budget updates = an updated release cost burn-up with trend lines
• Corrective actions = depending on the constraints, modify scope or timing or budget
• Estimate at completion = an updated cost burn-up with trend lines
• Lessons learned = a mandate of the project board to implement improvements that help the team to deliver more value for money.

If cost is your major constraint, and there’s no way you can get additional funding, then this is something you want to watch closely, even in an agile project.  You can do this with a cost burn-up chart.

The chart shows how much budget has been spent during the previous sprints.  We can calculate this, because we have the invoices of all our team members.  It’s just a matter of distributing the monthly timesheet data to the sprints.

But we also need a budget forecast.  This can be calculated because:

• We know how many sprints we need to complete the project, thanks to our velocity measurements and our up-to-date product backlog.
• We forecast how many days each team member will be present during the remaining sprints.

If you enter the actuals after each sprint, you can use this graph to monitor your cost and it’s evolution on a regular basis.

Again, the chart doesn’t give you one precise number, it gives you a best case, an average case and a worst case scenario.  This is key to all agile reporting.  There is a cone of uncertainty, let’s not ignore it.  Instead, monitor it continuously and act accordingly.

A budget burn-up chart is a great tool for reporting to senior management, for instance in a project board.  In an agile team, the product owner carries responsibility for the budget.  However, when things get out of bound, it is often the project board who takes decisions.  When budget is the major constraint, you have to work with time or scope.

As a product owner, you can prepare such a project board meeting.
OK, we’re heading towards a budget overrun, let’s prepare some corrective actions.

For example:

• We can drop feature 120.
• We can go for a simplified version of features 121 and 122.
• We will release one sprint earlier and move features 121 and 122 to a next release.
• These are user stories that were added to the backlog, are they all necessary?
• The team has identified these organizational impediments that hinder their performance.
•  …

Many people think that it is impossible to report about budget in an agile project.  Actually it is pretty easy, once you realize that the only things you need are invoices, an up to date product backlog, sprint measurements and a team capacity forecast.

2. Schedule control

The second controlling process of PMBOK is schedule control, which goal is to assess the current status of the schedule and determine the variance from the baseline.  By understanding the cause, appropriate actions can be taken.

There are typically 3 inputs that are used in schedule control:

• the project schedule
• performance reports
• change requests

As outputs we usually see things like:

• Updates of
  • the schedule baseline
  • activity lists
  • the project management plan
• Recommended corrective actions

Sounds heavy, right?

Let me try and translate it into the agile terminology.

In an agile project, schedule can be an important constraint too.  In most software development projects, people are your major cost. Which means, the longer they work, the more budget will be spent.  This doesn’t mean we can’t be flexible with our schedule, it means that our investors continuously want to see actuals and forecasts.

In other agile projects, schedule is the constraint, not (primarily) because of the cost associated with it, but because they need to release before a certain date (ex. The Christmas holiday season)

Again you see the same pattern.  There are constraints, but by identifying the primary one we define our reporting behavior.

What would be the input of your ‘agile’ schedule control?

• the project schedule = your release burn-up with trend lines
• performance reports = the velocity of previous sprints
• change requests = the evolution of your product backlog

+ improvement suggestions that are outside of the team’s control

What would be the output?

• Updates of
  • The schedule baseline = decreasing the product backlog or adding another sprint
  • Activity lists = n/a.  Since an agile team is cross functional and delivers pieces of functionality in the state of production ready in iterations.
  • Project management plan = change the order of the user stories in the product backlog
• Recommended corrective actions = a mandate of the project board to implement improvements that help the team to perform more efficiently.

Let’s look at an example.

Suppose I use this burn-up chart to report about schedule to the project board:

Then I would show them that as to date, the team has completed 210 story points of the product backlog.  If we look at the trend lines, this would mean that in an average case, we would complete the project in sprint 12. I would also point out that the schedule has slipped with one extra sprint because of an increase of the product backlog in sprint 9.

At this point, my stakeholders may have enough data to take decisions.  If the project is still within its original expectations, they might decide to just carry on.

But if we absolutely needed to finish in sprint 11 (for budgetary or marketing reasons) they need to make a decision.

Your stakeholders will need extra detailed information, depending on the cause:

1. The product backlog has grown

Why has it grown? Did we forget something? Is it essential?

Now you need to be able to zoom into the backlog.  Probably not to a user story level, but at least to a feature level.  As a product owner, you need to tell them why this new feature was added, and why it’s important.  With this information, the stakeholders can weigh their decision and decide to:

• Move a less important feature to next release.
• Give the product owner the mandate to reduce the scope of some other features.
• Agree with the extra time (& cost)

In this case, it’s not wise to add extra capacity to the team, because that only has an effect in the long run.

2. The team’s velocity is dropping

This is where you bring your retrospective data.  What have you discovered?  And most importantly, are there issues that cannot be improved by the team?

This is the time and place to get a mandate for bigger improvements.  Everybody sees the impact of your organizational inefficiency in terms of schedule and cost. And this is a powerful persuader.

So again, it is quite easy to use the project burn-up chart to report about schedule in the same format a PMP is used to.

In essence, the only organizational change that is a must is to agree that projects carry a level of uncertainty.

I hear you thinking: “That’s just common sense, everybody knows that!”.  Indeed! Everybody knows it, but many refuse to acknowledge it.

It is essential that your company’s leadership agrees on this.  This is the only way to start managing projects in an agile fashion, which is based on:

• Regular feedback
• Transparency

Two things that are essential to keep a project on course by making decisions on a regular basis.

If on the other hand, your leadership does not acknowledge the uncertainty of projects, projects don’t need feedback cycles or transparency, because they are cast in stone and will be delivered as planned anyway.

If they do acknowledge this, you don’t need to change much to the current organizational processes for starters.  If you’re a project manager in an organization that manages its projects the way PMBOK prescribes, you’re probably sending performance reports to your stakeholders or hosting monthly project boards.

Because this is a model of management by exception, you’re only supposed to bother them with details when things go wrong.
So typically, your performance reporting consists of:

• Status reporting
• Progress reporting
• Forecasting

PMBOK contains 5 Controlling processes:

• Scope Change Control
• Schedule Control
• Cost Control
• Quality Control
• Risk Response Control

The output of these processes is the input of your performance reporting.  Sounds very heavyweight, doesn’t it?

In this blog post I’ll show you how you can easily keep your performance reporting in this format when you’re dealing with an agile project.

1. Scope Change Control

This process tries to structure the way scope changes need to be dealt with.

Typically, the work breakdown structure (WBS) acts as the project’s scope baseline.  A change request needs to be formally approved in order to be included in a new version of the WBS, so that a corrective action can be included into the project plan.

A process like this is critical when you’re working in a fixed price, fixed scope contract.  Each change that was not part of the contract needs to be tracked, approved and funded.  That’s common sense right?  If you’re contractually bound to deliver a scope for a fixed amount of labor, you want to make sure that the scope is well-defined and you only spend time on what’s in that contract.  All additional work might make sense for a user, but will not be paid for and therefore will endanger your project success.

In an agile project, the concept phase of a project is significantly smaller.  For various reasons, it makes more sense to start with a high level scope description and high level project plan, which we will expand later through learning and feedback.

This means that it is much more difficult to decide whether or not something is a change.  Actually, a change is treated differently.  Where in our classical Scope Change Control process, a change is treated as a danger, in an agile project it is treated as an opportunity.  Learning or feedback have emerged the discussion of a potential change, which is then weighed and the change enters the product backlog at a specific place or not at all.

In my opinion, it is still healthy to report about Scope Change.  Because in an agile project you’re also working with constraints.
Maybe you need to realize a certain minimum scope, maybe you have a maximum budget or maybe you need to release before a certain date.  I call this the primary project focus.  The one thing that is most important.  The one thing we hate to tamper with.

Instead of reporting on the list of change requests against the WBS, in an agile project you can report about the evolution of the size of the product backlog.  By definition, content is variable to a certain extent, because we started with a high-level scope description.
So it’s no surprise that the scope is changing.  What is most important is to keep an eye on the total size of the product backlog.
Because you don’t have unlimited resources, the scope can only grow so far.  If your product owner can compensate the growth by removing other pieces of the product backlog, no action needs to be taken.  But in some cases, the product backlog grows too much.  This is a case when management by exception takes place.  The project board needs to take a decision.  Additional funding, yes or no?  Altering scope, yes or no? …

This may sound bureaucratic to most agile enthusiasts, but it matches the idea behind the product owner role.  She gets the mandate to represent all stakeholders and take decisions about the product, until a certain level.  Within the dimension of scope, a product owner may get the mandate to take decisions as long as all 6 epics are covered and the total amount stays lower than 300 story points.

In an agile project you can report about scope change with the use of a burn-up chart.

As you can see, the red line represents the total size of the product backlog.  As it evolves, you can plot a new point after each sprint.  This shows the evolution in the product backlog size to the project board.  So besides the actual total, they can also see the evolution.

This seems very high level, which it is.  But remember, the project board manages by exception and is not interested in the detail evolution of the product backlog.  It has given a mandate to the product owner to manage that.

What data do you need to create this graph in excel?  This is what my data table looks like:

The burn-up chart can also be used for reporting about the other PMBOK Controlling processes, but I’ll leave that for next blog posts.

I’ve seen continuous improvement as a great motivator for people.  In Agile teams, the retrospective meeting can evolve into a catalyst for learning.  It is not uncommon that people, who have lost their enthusiasm for the trade after years of the same old company politics, start to revive.  Suddenly, they get listened to!  The retrospective becomes their tool to contribute improvements to the organization.  It feels fresh, open and in many cases they have plenty of ideas.

Although this all sounds great, there is a danger in this enthusiasm.  Because what happens when people bring up new ideas?  They expect all of them to be implemented!

Since a retrospective is focused on a single iteration, most improvement suggestions are based on the previous x weeks.  That’s why many Agile teams only seem to improve a little over time.  Sure a lot changes between iterations, but that’s often not directly proportional to the effort it takes to implement these improvements.

What is lacking is a long-term view.  What’s our ideal model?  How do we want to work together?  How will we deliver value to our customers?  How do we integrate with the rest of the organization?

This seems like a dreamy exercise, but beware of its value.  Having an ideal model gives you the ability to weigh your options.  Why would we waste our energy on improvements that don’t contribute to getting closer to our ideal model?  It’s not uncommon that an improvement suggestion gets us farther from our ideal state.  Besides that, it’s simply a fun exercise to imagine a perfect world.

This process has been used for a long time in other industries.  Check out Toyota Kata, if you’re interested to learn about it in a manufacturing context.

In the book, you can read about the Improvement Kata, which has 3 actions:

1. Understand the current condition
2. Identify the gap with the vision
3. Set the next target condition

As you can probably feel, this is an iterative model, where you cycle through the process in a quest to get closer to the vision.

Let me show you how I use the vision during Agile retrospectives.

Visualize the ideal state

If we want to understand our ideal way of working, we need to be able to use it easily.  So in one of our team retrospectives, we focused on writing down our ideal future.  This was a highly interactive meeting, where we started by writing down the stuff that mattered to us.

Then we tried to group items by similarity or category.  Doubles or similar topics were combined until the model became small enough to make it easy to understand, without losing too much meaning.

In the end, I consolidated it in a mind map.  This way, we could easily re-use it in future retrospectives.

Use it as an exercise starter

In some retrospectives, we use the mind map as a starting point.  By going over the different categories, we identify the current gap between current reality and our ideal way of working.

This works as a great conversation starter.  You can attach different retrospective exercises to this, for instance root cause analysis, brain writing, …  Whatever exercise helps the team to get insights in why the gap exists for a specific category in our ideal model.

Finally, we would come up with actions to take a next step, closer to our ideal model.

By using this format, you remove the issue of choosing improvement actions that contradict each other over time, because you start the exercise from the vision.

Use it as a cross-check

In other retrospectives, we follow the standard retrospective format.  We gather data about the previous iteration and try to generate insights.

It is however during the ‘define actions’ part of the meeting, that we include the mind map.  We use it to cross check our possible improvement actions and whether they conflict with our ideal model.

In this format you filter out the improvement actions that contradict the vision.

Observe the impact

In the next retrospective(s), we check the results of the implemented improvement actions.  Did they bring us the next target condition?  If so, we can start working on defining a new one.  If not, we try to understand what happened and brainstorm new improvements that can get us to the next step.  And in some cases, it can take a few retrospectives to eventually reach the target condition.

On an abstract level, the vision has become an essential piece in our continuous improvement toolbox.  It is an essential part of the puzzle to make improvements sustainable and to keep growing as a team.

I wrote about the 5 most common arguments against Kanban in my e-book Kanban for Skeptics.

1. We lose our ability to plan
2. It will take longer
3. Things will get stuck — we can’t keep WIP limits
4. Stakeholders don’t care about feeding the flow
5. We will lose team cohesion

My request to the readers was to send me new arguments and help me to improve the book. Seems like the most popular argument against Kanban is: “Software development is not manufacturing“.  In the latest version of the book, I added a response to this argument by comparing the design phase of a car and manufacturing.

When you learn about the origin of Kanban, people quickly understand that a WIP limited pull system makes a lot of sense in manufacturing.  Even in industry, most manufacturers have jumped on the lean wagon, trying to bridge the gap that Toyota has created decades ago.  Lean manufacturing nowadays is mainstream in modern industry, there’s not much more to gain there.

The major battlefield lies in product development.  Consumers want new products at a much faster speed than they used to.  Companies that are able to create new products at a faster speed, gain an enormous advantage on their competitors.

Developing a new idea from concept to product is a completely different game than assembling a product en masse.  It is characterized by:

• creative thinking
• continuous testing of new ideas
• seeking as much feedback as possible
• intense discussions

This feels quite similar to a software development project, doesn’t it?  Especially since most software applications are only created once, and certainly not reproduced over and over again.

Environments like these are hard to manage, let alone plan.  It is no surprise that in most organizations the life-cycle of designing a new product takes years.  An increasingly number of organizations starts to feel the need to reduce their time to market.  Lean product development tries to offer a solution by attacking waste in product development head on.

Software industry folks will instantly recognize some of the characteristics:

• Strong leadership
• Cross-functional teams
• Set-Based Concurrent Engineering
• Short feedback loops
• Focus on the customer and supplier
• Cadence, Pull, and Flow

This looks a lot like Agile, right?  Aren’t we applying the same principles in Agile projects?

• the Product owner role
• Cross-functional teams
• Delivering working increments
• Time boxed iterations

Indeed we do!  It’s the only way to deal with a world that is full of hypotheses and uncertainty. Instead of trying to predict the future, we acknowledge its uncertainty and organize our-self to learn fast and make good decisions.

Now how does Kanban fit into this picture?  First you need to change your perception.  Stop looking at Kanban as a tool that helps to improve your progress efficiency, because it’s much more than that.  Look at Kanban as a way to introduce pull into your product development teams, a major waste reduction.  Instead of holding on to a plan, we focus on learning and adjusting our course accordingly. Just as lean product development says: ‘Create multiple alternatives and gradually eliminate the weaker options’.  The concept of feeding a Kanban flow matches perfectly.  Limiting WIP will give you fast feedback and makes it easier to adjust course.  If a cadence is useful for keeping focus or creating rhythm, do so.  Kanban allows you to work in a continuous flow or in a cadence.

If you take it to an abstract level, lean product development and lean manufacturing are built on the same ideas and principles.  Their actual application differs significantly.  Where in manufacturing the focus lies on efficiency, in product development the major focus is dealing with the uncertainty of creativity and innovation.

The same difference is found in the application of Kanban in software development.  Software development teams use Kanban to deal with uncertainty.  Support and operations teams use Kanban to improve efficiency.  Nevertheless, both follow the same principles.

(image by ChrisM70)