The desire to change

Suppose one day, after a particularly bad hangover, you decide to change your life.  You long for a trim body, a balanced spirit, lots of energy and no more headaches. In short, a happy mind in a healthy, good looking body. But how do you get there?

Well, we all know that there are many practices that will help you achieve those goals.  Exercise three times a week, stop smoking, reduce your alcohol intake, and change your eating patterns. Oh, also, get more sleep, less stress, no more pills, and drink herbal tea instead of espressos.

But you hate sports, you love chocolate and smoking is your way to reduce your stress.  So what do you do?

The daily fruit practice

In order to get healthy, you decide that from now on, every day, you will eat a piece of fruit at lunch.   It’s pretty easy to do, even though you don’t like fruit very much.  So now you are satisfied, you do a healthy thing every day, and you expect to reach your goals (more energy! greater happiness! better looks!) anytime soon.

Will you? Of course not! While the daily piece of fruit is a step in the right direction, you will never fully get the benefits you are seeking if you keep up your old habits of smoking, drinking and eating greasy food,. And after a while you might even get disappointed and frustrated, and you will decide to stop eating fruit, claiming that “a healthy lifestyle simply doesn’t work for you”.

Doing just one healthy practice, or even a couple of them, isn’t enough. What you really need is to change your mindset. You want to be a healthy person, not do some healthy stuff. Once the healthy mindset becomes your way of life, the practices will simply be the natural way to go. And they will be a lot easier to start with and maintain for a long time.

The daily Agile practice

The same applies to Agile. We see many companies and teams that ‘ do‘ Agile. They take a couple of practices from an Agile framework such as Scrum, and they figure that that will be enough to give them all the Agile benefits. Some teams even think that if they just do a daily stand-up, they do ‘ Agile’.  While daily stand-ups, just like that daily piece of fruit, are definitely a good practice, your are still far removed from true agility if the rest of your behaviour consists of old, non-Agile practices.

A company or team only gets the most out of being Agile, when its mindset is based on the Agile principles stated in the Agile manifesto, such as continuous learning at all levels in the organization, business and IT working closely together, delivering the highest business value first, welcoming change, and creating an environment where motivated individuals can be creative and self-directing.

So if you are doing ‘some’ Agile, expand your practices. But more importantly, change your mindset. Don’t do Agile, be Agile. And remember:

One practice a day does not keep the old habits away…

The perceived need for scaling could follow as a reaction to the scope of the project at hand. It is quite common within projects to try and do as much as possible parallel development of different semi-detached functional areas of the product. This comes quite close to how I used to manage projects in the past. Whatever in the same timebox could be done in parallel, should. I was very efficiency driven back then, but also taught and stimulated to think this way.
Within this paradigm it would be preferable, that the PO has some sort of party around him helping to create the user stories he would be in charge of. Creating big teams gives us more capacity to do more work in our timebox. Larger teams and more work create the need for more coordination, because of limited span of control, thus creating the need to scale.

Also, I think we are still very much driven by the paradigm of the chain of command. It is simply comfortable when there is someone who can make the tough decisions for us and mediate between us whenever conflicting interests arise. The need for extra coordination between and over PO’s in the same context thus fits very naturally with our needs in a growing project context.
Come to think of it, maybe it is no coincidence that the person designated CPO is more times than not the first PO that was on the project. If we look deep within ourselves wouldn’t every PO actually want their first project steps to be so successful, that the extra means are granted to grow the team and consequently rise above to lead the way as CPO? And should we be that CPO, would we ever fully trust another colleague with the work we carefully prepared and poured our blood sweat and tears into? It would be great if we could somehow keep some sort of supervision on the others. Make sure the projects success and our hard work isn’t killed off in the next sprint or two. Scaling with a CPO construction would provide means to fulfill these needs.

Of course the above reasons to scale could be valid, but there are also downsides to them.

Although doing parallel work may sound efficient, maybe validation with your customers shows that the product increment doesn’t fulfill their needs as thought up in the first place. Since you have done a lot of parallel work, the risk of waste is also greater. Should you need to radically pivot your product in another direction, it will be much harder due to the already large scale of your operation.
I thus think that scaling towards having different teams work on the same backlog potentially inhibits us from maximizing validated business value, as you are pulling forward less important features from the backlog, before actually validating and thereby knowing whether you have actually delivered value with your top items. From this angle, it would be wise considering not to scale.

When scaling from success, we run the risk of slipping into a power monger mode and form a team beneath us to gain status and control instead of branching out sideways.
When this happens we are not working towards joint company stakeholdership any more, but we trying to build our own ivory towers. When the CPO leading the PO’s claims decisive power in certain areas, I believe you would not be creating the right entrepreneurial environment in which decisions are based on arguments and value for the customer and company. Maybe, as a PO, if you already know you need a decision from the CPO, you are inclined to use other influencing methods rather than comparable and less subjective measures than for example business cases, jeopardizing the quality of decision making and therefore the success of the product.

During my study, I was taught “there is no one best way to organize”. I think of this line as a universal truth, that in my opinion also applies to scaling the PO role. I therefor think that form is less important than the route taking you there. Knowing that there are risks involved in scaling and consciously dealing with them helps you along this route to find a form that works for you.

(*)Scaling is also common in productline contexts (for instance a CPO over a group of PO’s managing a product family) or within business units where you would have various strategic themes that the CPO would like to have implemented over the same time period.

Getting a view on innovation
When a company fills in a portfolio tool like a Boston Consulting Group (BCG) matrix, it gets a view on its product market combination (PMC) portfolio. You can tell a lot about the company and its business from how a BCG matrix (*) develops over time. One of the most fun things in my eyes is the amount of question marks turning into stars. A question mark being a PMC in a high growth, low share section (e.g.; doing something relatively new), a star being a PMC in a high growth, high share section (e.g.; being successful in doing new stuff).

The amount of question marks in the portfolio illustrates the amount of newly launched PMC’s on to target markets. When you also consider the amount of ideas not becoming question marks, and turn this into a ratio, you could get some idea on how innovative the company is. Add to his the amount of question marks turned into stars and you really get a sense of outward successful innovation. I distinguish outward and inward innovation, because I believe that experiencing a commercial hypothesis to be proved wrong is at least just as valuable as seeing it proved right.
This doesn’t mean that innovation can’t be applied in other quadrants, just that it might not be the smartest thing to do when for instance handling dogs. In many cases adding features to cash cow products can be a brilliant strategy. Take for example razors, where adding more razorblades, self-adjusting blades and other sleight handling improvements constantly extends the product lifecycle.

Innovation flavours
To get an idea of how scrum could accommodate for innovation, first we have to get an idea on the various sorts of innovation like “additive innovation” out there. In general there are four forms of innovation a company can venture into:

Incremental innovation: small improvements leading to slightly better results

Additive Innovation: adding product features, customization, new products in existing business lines

Complementary innovation: creating new offerings new in current business, but adjacent to current product lines

Radical innovation: doing completely new things, unknown to business and/or target markets.

Using agile to suit innovation
In the following section I will highlight a couple of alternative ways in which you could use agile and scrum mechanics to shape and facilitate these forms of innovation:

Incremental innovation:
1. Spend a retrospective or a section on this product improvement; try to get in one small improvement each sprint. Maybe this will ease the team into providing more input for the backlog.
2. Agree with the team that every sprint every individual team member comes up with at least one idea to improve the product in some way.

Additive innovation:
1. Create spikes in sprints to prototype new features, validate these with customers;
2. Hold demo like meetings with your target audience; ask them what they think about the product.

Complementary innovation
1. Keep key options open, have stories worked out in two variations and do validate these paths in spikes and demo meetings;
2. Invest time in finding the appropriate product owner for the job. Market and customer knowledge is important here as the company is going to serve adjacent and different markets than before;
3. Take care that the entire DMU is taken into account in the story map. Also look at internal impact of providing new services and products, for instance customer service needs.

Radical innovation
1. Make sure the innovation team is freed from all organizational gravity. Pull them away from status quo and peer paradigms;
2. Reserve time for existing teams to work on a free format project. This could be a once every month time box of a day for example. It can be whatever they would like, as log as results are made transparent. Let them the same social objects as in scrum (boards, graphs, backlogs);
3. Take care that you have means to measure relevant metrics early on. Every addition should increase sales, market share and other relevant metrics. Use retrospectives to find root causes and steer through story map;
4. Keep all options open, incorporate A/B tests, multi-variant tests, prototypes, feature polls and so on. Sprint goals are hypotheses you would like to see validated.

What I love about scrum, is that it so lightweight and adaptable. On the incremental- to radical innovation scale, there is no step in which scrum can’t be adapted to accommodate for innovation while remaining to move fast.

The above list is just a brain dump of what I quickly came up with. I am convinced that there are many more creative ways in which we could adapt agile and scrum practices towards innovation. Please view this blog as an open invite to share your thoughts on this subject.

PS: Merry Christmas and a very Happy New Year!

(*)A BCG matrix says nothing about profitability of the PMC, so market share in a growth market could be labeled as a vanity metric. The matrix also builds on the premise that you know a market to put question marks in. Sometimes however you don’t know what your market is going to be. Furthermore, the BCG matrix can be filled in numerous ways depending on how you define for example the market scope.

All these questions could and probably will play a role in the consumer
buying process of complex products and therefore ultimately decide whether product “a” is bought or competitor “b”. It’s not said all of these questions get asked and answered by the same person(a). Most buying decisions of complex nature are made by a so called decision making unit or DMU.

Decision Making Unit theory indicates a number of roles with regards to
buying decisions such as the:

- initiator : identifies problem/ need to solve;
- gatekeeper: regulates info for decision;
- influencer: influences decision;
- buyer: buys solution;
- decider: decides what product to buy;
- user: actual user of product;

We build storymaps based on pragmatic personas, which are primarily users. Selling our product however, as decision making theory shows us, may mean tactically taking into account the entire decision making unit, not only the users. I encounter a lot of releasable walking product skeletons, neither shippable nor marketable.
Too thin a walking skeleton, means releasable, but no one will buy it. Too fat a walking skeleton, means putting in too much and missing crucial market windows.

A sellable increment, which if possible is of course also a first release, means fleshing out your skeleton just a bit more making it more of a sellable Frankenstein than just a bag of bones.

A sellable increment or marketable feature set, in my opinion is your
kano threshold attributes + a well thought-out and implemented set of performance attributes, resulting in the product being a viable option in the customers consideration set of alternatives. Next to that, we need a good usp, or a unique set of these, positioning your product from all others. All of these product properties, or a specific set depending on your product marketing strategy, will need to be translated to DMU needs, to be able to hone the product for sales.

My advice would be to start thinking about the DMU and how this works for your product. Get marketing involved and see what they already know about the composition of the DMU. Create some peronas and try to involve them somehow in demos and future plans to get the feedback you need.

I encountered a lot of story-maps based on this principle in financial services lately. The “hello world”-first slice, or walking skeleton, comprised of nothing more than the bare minimum technical necessities to get a working chain environment end-to end. Later being fleshed out with additional functionality.

Most of the times this is the right thing to do, because in most cases there are dependencies with other systems and internal “suppliers”. The risk to see whether the system would work with these external systems later on in the project is too big to postpone, to when the features come up that possibly depend on these external pieces of the product puzzle.
Getting these dependencies out of the way, means seeing a working chain and having a better picture of how things work, mitigating the risk associated with delaying dependencies. For the external factors it means building the essentials and stubbing the rest, creating the barest technical walking skeleton possible, a working end-to-end chain.

Strangely some projects I saw with large amounts of external dependencies did see the value of this possibility, but still decided to go for a more functional first slice of the product, leaving them struggling for months before delivering end-to-end working software. How could this be?

The issue here was, that at the start of the project people all saw the dependencies but none of them could be addressed effectively. The major issue was the fact that all but one external supplier to the project were actually other internal departments that couldn’t/ wouldn’t lend resources and rather stick to their own release calendars (making them real old skool stakeholders by the way which is pretty evil). They also had a lot of problems getting their own environments from outside of the project, which didn’t help as well.

In the ideal world this project should not have started without the necessary support in place to complete the first ideal optimal technical slice in a couple of sprints. Which is actually not so different from when you create a regular walking skeleton come to think of it ☺. Remember to keep a technical walking skeleton an option when working in complex chain environment and or existing system environments. You might be amazed how fast you can get the first feedback, from customers and other stakesharers.

Should you have some interesting other slicing dimensions you would like to share, or you totally disagree with me, please leave a comment below! Many thanks in advance.

Angry, because they felt they were being held down by the system. As junior developers they only got to do simple, boring work.  They were unable to show all their knowledge, or use the cool things they had learned in college. Their salary matched the level of the work they did, and this was another big frustration.

Then one day the company decided to transfer to Agile, and the lives of Nick, Martijn and Harold changed. While in the beginning it looked like a great improvement, the young men soon got trapped…

The Invincibles

Nick, Martijn and Harold eagerly volunteered to be on one of the first Agile pilot teams, together with a senior developer, two testers and a Scrum Master.  They bonded quickly and called themselves the Invincibles.

Now Nick, Martijn and Harold got the opportunity to show their skills. They took on hard programming challenges. They paired with the senior developer and the testers. They learned from them, but also taught them a lot. Things were great, and this was only the beginning.

Their velocity was at 18 points.

The Invincibles were highly competitive. They were determined to prove that they were the best team of all. Since velocity was important, they made sure their velocity went up. Sprint after Sprint. They delivered what they committed to, and even more.

Their velocity was now at 25 points.

The stakeholders loved them. Management loved them. Their team was set as an example to the entire company.

In order to increase their velocity even more and meet their ever-growing commitment, the Invincibles started to do overtime.  Our young men enjoyed these evenings a lot. Free pizza and Coke! Male bonding.  It felt just like the good old days back in College.

And velocity reached a stunning 30 points.

One overtime evening turned into two, two into an entire weekend… At the Sprint Demo, the Invincibles turned up bleary eyed and unshaven. But they had once again broken their velocity record, and the stakeholders were simply thrilled.

Velocity was up to 40 points!

The atmosphere in the team became more and more competitive.  The senior developer could not keep up with the young men’s high pace.  So they kicked him out as they felt that he was slowing down the team.
One of the testers, who had 3 young children, was unable to participate in all the overtime nights. He had to leave, too. Only people with the true Invincible spirit were tolerated on the team.

The stakeholders, who were facing a product release, kept pushing for a higher velocity. They simply needed all the functionality in the release. They knew the Invincibles could do 40 points! Eager to please them, the Invincibles agreed to do it  once again.

However, even young men get tired. They started to cut corners in order to keep up the high velocity. The number of bugs increased.  Technical debt increased.  But they were still satisfying their stakeholders, which was their main concern.

40 points! Again! And Overtime. Once more.

The day of the release, they were worn out. They had spent so many nights at the office. At the same time they were also very proud and relieved. They had made it! All the stories the stakeholders had asked for were in the release. When they went home after deployment they already imagined the huge party the stakeholders would throw for them…

The release was a disaster.

Major defects. Furious stakeholders. Escalations. Angry executives. No party.

The Invincibles were miserable. While they had tried so hard to please everyone, in the end nobody was happy.  Was this what they had worked so hard for?

The Invincibles had fallen into the velocity trap.

—————————————————————————————-

What happened to Nick, Martijn and Harold?  Well, they were young and they bounced back.  And they learned.

They still like to challenge themselves, but they have learned to set their limits.  They have grown more respectful of their colleagues. They refuse to cut corners.  And they often have pizza and beer together, but outside of work.

The quality of their work has increased, the team atmosphere has improved, and this has lead to a stable, high velocity.

The Invincibles have now truly become invincible.

At that time I was the project manager and scrum master of a software development team. As a team we embarked on our exciting mission to develop a new product. We did this in a Scrummish, more or less Agile way.

We set-up a continuous integration environment and we measured a lot of things. The metrics we collected included #PMD violations, unit tests ok/failed, #FitNesse tests ok/failed, code coverage, cyclomatic complexity, distance, velocity, etc.
For the product we knew that performance was going to be very important. So we ran various automated benchmarks on a daily basis. The results were collected automatically by the build system and stored in a database for reporting purposes.

Besides that I needed this to report to management, it was also quite fun to implement

Dashboard

Then I had a brilliant idea: it would help the team if I would make all this information available on a dashboard! So I spent a couple of months (including lots private spare time) implementing this based on JBoss, Pentaho Portal/Reporting, and MySQL. While implementing this I learned a lot about portals and Pentaho. On the portal side of it, the team members could define their own dashboard and view on the metrics. Cool.

Except…..nobody (except for myself) looked at it…..how come?

Coffee Machine

In the weeks that followed going live with the dashboard it struck me that team members stood by the kanban board discussing possible bottlenecks and what to do about these. The kanban board happened to be within 2 meters of the kitchen where the coffee machine stood.

So what happened was that every time people went to get a cup of coffee, they gathered by the kanban board (because the kitchen was too small) and discussed the latests events and what to do about it!

…..the next day I printed some of the most important charts and stuck them at an empty spot on the whiteboard. Guess what happened!

Conclusion

Before deciding on a tool think about what you want to achieve with it. In the example above the goal of automatically collecting metrics and create charts was OK, but having an electronic dashboard to replace interactions within the team was not a very good idea. That was time to eat my own failure cake, with a cup of coffee.

More focus on “the string of rights” generally brings a great deal of success but also a lot of stress to cope with. The stress comes from the fact, that if all capacity in our production system is focused on doing the “rights”, that those “rights” might not always be the “rights” you are responsible and accountable for right now.

Dealing with the stress means stakeholders have to change their attitudes from viewing themselves as stakekeeper to stakesharer. Stakesharers put more value on the overall company results than the stakes they hold (semi) individually. This as opposed to stakekeepers. To facilitate “stakesharership” means, we have to scan our organizational context to see what elements are not aligned with the concept and to improve on them (e.g.; communication structures for dealt portfolio management, job descriptions, budget-management processes, leadership styles etc.)

Your focus on the string of rights increases if there are less stakekeepers around, as Burm’s formula for joint company stakeholdership shows us:

If there are also mature teams with enough sense of responsibility and involvement to become staketakers, chances are your increased focus on value and joint company stakeholdership are just around the corner.

Say goodbye to traditional stakeholdership. If you want to create real ownership in your agile company and maximize focus on value delivery, embrace the concept of joint company stakeholdership today!

PS: If you fill in Burm’s formula for your company right now, how would you score?

Since this question surfaces every now and then, answers collect here (in alphabetical order).

• Agile Bench
• Google Docs
• Microsoft » Excel
• FlowKaizen
• Atlassian » Greenhopper for JIRA
• Hansoft
• Bandit Software » LeanKit Kanban
• Pivot Labs » Pivotal Tracker
• Rally Software » Rally
• ScrumDesk
• Silver Stripe » Silver Catalyst
• smartQ
• TargetProcess
• Version One Suite
• Atlassian » Vodafone wins Ultimate Scrum Board Award

Got more?

Contributors:

• Serge Beaumont
• Erica
• Theo Gerrits
• Olav Maassen
• Pieter Rijken
• Yves Hanoulle
• Jem

But the question (and the initial answers) kept nagging at me all day. And while I sat down with a glass of good whisky in the evening I got back to the question. Here is what I came up with:

• Agile is simple, not easy
• Experience bootstraps learning
• Organizational gravity

Agile is simple, not easy

Any agile methodology is usually very light on rules and have-to-dos. That makes it simple, but not easy.
Behind and because of those simple rules there are still very complicated issues.
“Features must be broken down into chunks that can be implemented in x days” is very simple, but very hard to do if you have no experience. (and sometimes even if you do have experience.)
“At the end of every sprint you need to have a retrospective”. Again very simple. But actually creating a team and environment that can really learn and improve their own process is hard.

So yes Agile is simple, but hard

Experience bootstraps learning

One of the most important things about Agile methodologies is that they make it possible and encourage learning teams.
Having someone with experience however allows a team to accelerate learning in the beginning. Someone who has been in a similar situation before can pick lessons learned and share those with the team so some wheels do not need to be reinvented. As long as the team only uses those ideas as a starting point for their own learning it can accelerate the initial learning.

Organization gravity

Lyssa Adkins has a brilliant quote in the book “Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition”.

“Gravity Works”. Yes it does. Rock climbers know this and plan for it. So do Agile coaches.

Agile transitions are not limited to the teams doing the actual development. They are part of much bigger picture. Other departments need to at least be aware of the transition and probably have to change considerably.
For example walk into the operation department of a big company that is doing waterfall projects and tell them that you are going to release every project every month. They’ll laugh at you.
Most managers actually really like the fake certainty of waterfall projects..
Agile does not solve any problems by itself, it just makes them painfully clear. Not all organizations are mature enough to realize that and will usually blame Agile for all those problems that are suddenly surfacing.

Those are only some examples where organizational gravity will play up. They will constantly pull your Agile transition towards the old status quo.
An experienced Agile coach will recognize those signals and work with the clients to keep an Agile transition on track towards the goals that were set.

Just like a regular coach.