The Myths with Alignment

At the moment there is lot of talk within in our great company of the need to align ways of working and tools across the organization.  Alignment is the new black, always political correct to argue. I think it comes from the desire to become a great systems thinking company that makes us scream for alignment. But is alignment a step in right direction? How is alignment really used?

It’s time to look closer at alignments, here are what I like to call “The Alignment Myths”

The Alignment Myths
    • Alignment Translates to “same way”
    • Alignment of Processes Save Costs
    • Alignment Makes Organizational Hand-overs More Efficient
    • Alignment of Tools Saves Costs
    • Alignment Gives Flexibility
    • Alignment Makes All to Work in the Best Way
    • Alignment Makes Control and Decision Easier

Myth: Alignment Means “same way”
Not that much a myth as it is an interpretation issue. Alignment wouldn’t be bad if it meant “make things work together”. Quite common though, is the interpretation that aligning ways of working means working in the same way, not working in different ways and align those. Alignment of tools interprets as using less number of tools, not that many tools shall work smoothly with each other.

Those myths exists mainly because the interpretation Alignment = “decide on ONE process and ONE tool”.

Myth: Alignment of Processes and Way of Working (WoW) Saves Costs
It might, but the real question should be “Does alignment create value?”

What we are learning (slowly) from the lean industry is that optimizing on value and performance (speed, throughput) have a greater meaning than optimizing on costs. At least both cost and value must be taken into account.

To illustrate:

The simple Alignment Justification Formula 

Product A is best developed with method X and creates value as AX
Product B is best developed with method Y and creates value as BY 
Coordination cost of this two different methods is Z 

Letting Product A be developed with method Y (AY) gives 
less value than AX (similar for product B) 

The calculation needed to justify an alignment:      
          AX+BY-Z < AY+BY (or AX+BX)

In words; If the coordination cost is less than the in-efficiency for using a non-tailor made process – Don’t align!

Too often this calculation is ignored and it is assumed that if Z is minimized it is beneficial.

Myth: Alignment Makes Organizational Hand-overs More Efficient
This is partly right, the hand-over may be more efficient but will we create more value? What makes this a myth is the assumption that an efficient hand-over will lead to an efficient development. This is often argued when several flows goes across two (or more) organizations. If everything coming into an organization does that in a similar way it will be more efficient to handle.

The receiving organization (Org.2) sees a great benefit if all flows in the previous step is looking the same as it will be easier to understand and structure the own work. That is correct, it will be easier for the organization, but as the structure above is according to the resource view, it will be an optimization on resources over value creation. In worst case all products may suffer but management of Org2 will sense a gain of efficiency.  Again, check the alignment justification formula!

Myth: Alignment of Tools Saves Costs
If we all can use just one tool we just have to buy one license. Here again we are looking at costs without reflecting on the value a tool is creating. Everybody understands that it’s probably substantial more than one tool required so usually the aim is to reduce number of tools. Let’s look at it from another angle: If it still is a lot of manual work in daily operations then we probably have too few tools. Why not aim to add some?

Myth: Alignment Gives Flexibility
If all teams are working in the same way with the same tools it will be easy to move people around.
Well, if we move people between teams, what will the real issue with performance be? Most likely will the impact from establishment two new teams (“moving from team” and “moving to team”)  overrule the impact from having different tools and methods. If you are a professional in what you are doing you will adapt to processes and tools faster than adapting to your new teams culture and personality. In practice you don’t have more flexibility as it isn’t the bottleneck – team and people are.

Further more is alignment preventing flexibility for making adaptations in processes and ways of working as they need to be hand shaken with several practitioners, often with another view on good adaptation. This myth is not just false it is even exactly the other way around – Alignment prevents flexibility

Myth: Alignment Makes All to Work in the Best Way
This assumes there is one best way of doing things. Most likely what’s best for one situation or product is not necessary best for another. A best way is that it is not necessary a good way, it’s just best.
If we believe in the lean way of improving, there is always a better way and the crucial thing is to have the system for systematic improvements (Kaizen) in place to iterate into a good way.
It is a high risk that the iterations will take longer time when all adaptations and changes must be aligned with all operations – Alignment may slows down continuous improvements

Myth: Alignment makes control and decision easier
A reason mentioned is that steering boards and control function must understand and be able to compare the different operations within the company. As alignment implicates that instead of working in exactly the way a certain work stream requires, it is working according to a trade-off suitable for several work streams. To make it easy and smooth for the management of the work streams but more complicated and inefficient for the people in the work stream. This is optimizing on the support function instead of the value added main flow.

Is it more important that daily life is easy for management or easy for the people working in the value creating flows?

Alignment of values and principles
Well, that’s the alignment that probably makes sense!

Conclusion

  • Alignment in the meaning of making all different ways of working and tools to work together is good
  • Alignment in the meaning of working in the same way, using the same tools is madness
  • Consider value creation, not only cost savings to avoid complete madness. (simple alignment formula)

Picture by tamara

Posted in Agile Thinking, Change, Coaching, Framework, Leadership, Lean, Myths, Organizaition, Processes, Transformation, Way if Working | Tagged , , , , , , , , , , | 4 Comments

Definition of Done for Coaching?

Wikipedia phrases Definition of Done as follows:

The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful.

Probably based on this I have lately been in discussions related to Coaching and DoD. The question that has been put on the table has been: what is the Definition of Done for coaching i.e when coaching is not anymore needed? I have been pretty confused about this and have been trying to think why this kind of angle seems to be very important to some people.

My conclusion is that when someone sees Lean-Agile transformation as a methods and process change this thinking also reflects to coaching. In general a process change has start and end stages. Then you apply the new process for a while and change it again (if there is seen a need). In this perspective I try to understand that this question might be natural to some people who think this way.

For me this is also clear indication that these people have not fully understood the change that Lean-Agile brings to the organizational mindset and culture. In reality the practices/process part is merely a tool that supports bigger, more fundamental change in organizations and especially how they are led. This is the key part that needs to be understood in its entirely before real change can happen. Agile is by nature empirical and has built-in the thinking of continuous improvement. How could continuous improvement have DoD?

Yet another viewpoint is traditional role thinking in large organizations. Usually process thinking implies that role descriptions are described in detail:

Top management must ensure the job responsibilities and authorities are clear defined and communicated to all level of people within the organization (ISO 9001)

Our organization has had a bit different approach into this. We have defined coaching based on the understanding in general agile and lean literature and put focus on the continuous communication and discussion, which is complemented with the nature of complex adaptive systems: you are not able to model it. Nor are you able to document what is a definitive role description for coaches.

To nail it: some people might see coaching as supporting activity during a process (Agile) change. This implies that Lean-Agile thinking has not yet fully reached these people. It is a warning sign to the organizations and to change this we have to apply more coaching.

Coaching is key asset and absolutely critical for modern R&D organizations to succeed on a long term. Coaching brings the values and thinking into the picture and helps organizations and people to overcome traditional process thinking. Many aspects of coaching touch the soft part of systems and organizations: how people interact and how could they continuously improve.

How it is in your organization?

Posted in Agile Thinking, Change, Coaching, Continuous Improvement, Leadership, Lean, Transformation | Tagged , , , , , , , , | 8 Comments

Product Ownership Evolution, part 2

Scaled-Up Scrum

Scrum is fairly simple from practices point of view (and claimed to be powerful, when applied correctly). You work in timeboxed iterations with a team, Product Owner and ScrumMaster. You apply certain ceremonies (Daily Scrum, Groomings/Sprint Planning, Retrospectives, Sprint Reviews). This is added with a couple of artifacts (Product/Sprint Backlog) and continued until end of the world. Unfortunately, when this approach is only applied on a practice level, the real promise is not met. Agile values and systems thinking are vital part of Scrum introduction, even in small scale. How about when you have multiple teams and complex business environment? One of the initial questions we faced was: Does it scale and if it does how should we plan? Scaling has actually many aspects that are not evident in the early phases of any Agile transformation. We made initial team scaling exercises but missed the understanding what end-to-end flow optimization means in terms of scaling Agile (and Scrum). It is hard to understand that we should focus only on work instead of workers. If you have too static structures that do not allow self-organization, easy self-selection and self-ordering you will have a mountain to climb. In our exercise many of the issues were and are accumulated in the Product Ownership function and inspecting that provided us many vital lessons and deeper understanding.

PO structure and scaling

There are some alternatives when scaling Product Owner role. One thumb rule is that one Product Owner can handle two-three teams (when applying by-the-book Scrum). On the other hand Scrum says that there is only one PO. With these guidelines we did the following: there was one PO and a bunch of Proxy-Product Owners matching the number of teams (one PO, two teams). When considering that we had 20+ teams the amount of POs was around 15. Our aim was to have also PO team work as a real team but without boundaries and structure this was not achieved.

In practice this also lead to a situation where lack of common goals resulted to sub-optimization on enterprise level: a feature/proxy PO was driving own features to “done” and common problems were someone else`s problem. As we were facing initial transformation challenges at the same time there were a lot of impediments that needed teams attention and effort. We tried to overcome this with adding management attention, which was really hard when considering management role within Agile: to support and help, leaving responsibility to teams. We even heard comments (from external consultants) that managers are not needed in Scrum… What we did not understand was that proxies are not a tool for scaling but a shortcut for bringing the business closer to the teams. So in reality teams felt that they were left alone and too much was asked from them. A common question that time was: “should every team do and be responsible of everything?”.

Lack of common vision and goals leads to unhealthy balance within an organization. In our case this resulted to feature focused approach where product and legacy aspects where down-prioritized and often neglected. This is violating against the purpose of any organization: satisfy/delight the customer with continuous delivery of valuable software and solutions.

A good example of this challenge was when we introduced Continuous Integration: feature POs only had interest on improving the items that directly provided value for their feature.  It was again someone else`s problem to put focus and business priority on the items that were connected to product or solution level. Not a very food approach in terms of “see the whole!”

When we understood that this approach was not fully working the decision was to get coaching towards the PO. I believe this was a good decision, but the coaching that was really needed was not answered. It is more important to address values and and behaviors instead of User Story writing techniques. Or learn how to work with the people instead how different items are handled in the backlog. I have asked from different organizations have they seen POs more on the operational dimension (execution) or change agents. The answer has always been on the operational side. When we realized all this we decided to apply a deeper change: introduce initial boundaries and structures into PO function to help the organization scale up and continue with the change. More of this in the next part of this series…

Posted in Agile Skills, Agile Thinking, CI, Coaching, Continuous Integration, Leadership, Lean, Product Owner, Scrum, Transformation, Uncategorized | Tagged , , , , , , , | Leave a comment

Dream of Radical Communication Boost

The other night I had a thoughtful dream….

I went to work an ordinary Monday morning. When entering the building I notice there was a non-typical morning, people where standing drinking coffee, talking about the weekend – it was a “waiting” atmosphere in the building. Didn’t took too long before someone told me that the mail system was down and every one waited for the servers to come back up again.  After awhile a rumor started to spread; There is a message on the Intranet announcing that all should show up for a all-hands meeting at 10am for further information about the mail system outage.

At 10 o’clock our top management had the following message:

– The mail system together with the meeting booking system is down and it will be down for at least some weeks. All other system seems to work perfect.
– There is nothing we can do to change that.
We can not afford to halt any development because of this.
It means that we all must do what ever it takes to continue design and produce our coming releases.
– It is NOT acceptable by any of you to blame the outage for anything.
Development in focus – solve the problem!

At first everybody seemed a bit lost but with a “let’s solve it”-attitude things started to move. While this was my dream I could make some “from-above” observations:

With the mail channel into the development teams cut off, the teams started to focus on team activities. Less requests for other things, less requests for changes during sprints.
The only contact with the other world for raising impediments, share progress, sync with other teams was via the daily scrum – presence and interests increased and made team spirit to grow. Productivity in teams where doubled.

To be able to sync and act fast enough without mail, a daily scrum of scrum was introduced and all of a sudden the complete progress was summarized at one place every day. It didn’t took long before the program control and management also met daily directly after the scrum of scrum to act on impediments and changes. Good and right project management support doubled the development capability even further.

While sending reports wasn’t possible and even calling for occasional meetings where hard, all status was gathered when the program team took the daily Gemba, visiting teams and project dash boards.
Every leadership team started to move around visiting every other management team face to face at frequent regular bases as that was the only way to get some what idea what was going on fast enough.
Getting rid of the reporting structure and other none value creating work boosted efficiency with another 100%.

Technical meetings and decision where posted on a blog, readable to all interested people. As they where discussed open, using discussion threads, the right people where involved – Decisions where better and deployment easier.

With those observations management realized they could not afford turning mail back on…

Here I woke up but I guess you can contribute with several more examples of “What if…..

Posted in communication, Framework, Fun, Leadership, Transformation, Uncategorized | 3 Comments

Next Generation will Demand Coaching

Next generation employees will take it for granted to get coaching when facing new tasks and challenges. It is being built in to their daily life(!) in, for me at least, a bit surprisingly way.

Just look what popped up when my 10-year-old started one of those multiuser team games the other day:

Image

So the gamers have realized that the fastest way to get a new player on-board is to immediately offer coaching help, explain goals, answer questions, show a few tricks, initiate communication and show interest in a new player. The underlying purpose here is of course to get the player motivated to stay on-line and continue to play the game, creating revenues for the gaming company. But there is no coincidence coaching is brought into the picture; research show Autonomous, Mastery and Purpose (Reference) being the main drivers for motivation and the gaming industry probably knows that coaching is a good way to boost those values.
When we like to attract skillful employees and have them “play” in our company for a long time we need to boost the same values – where coaching most likely is a very useful tool.

Regardless of purpose, Kids of today will get used to take help and be open for coaching when facing challenges and new tasks. I will be the natural way of learning. And when they realize that, do you think they will accept a slower way to learn when entering the job market?I think they will require coaching by their coming employer.

Cheers
Johan (Welund) Westerlund

PS. In our Telecom software industry we are often looking at the gaming industry as they are ahead in many software development processes with their frequent releases and customer responsiveness, now it turns out they are doing quite well in people management skills as well…

PS2: Transcription of picture “Do you want a coach? Do you like help from another player in your current game? ….”

Posted in Change, Coaching, Leadership, Transformation, Uncategorized | Tagged , , , , | 2 Comments

Product Ownership Evolution, part 1

This post is the first (out of 4) of blog series about Product Ownership Evolution. Our organization has been evolving quite a bit in our Product Ownership thinking and understanding during our transformation journey. In these blog posts I try to summarize our main approaches, the evolution and some thinking and challenges that have been visible in our context (some of these thoughts may also be something you can relate to).

1. Simplistic Scrum approach (this post)

2. Scaled-Up Scrum (part 2)

3. Requirement Areas (part 3)

4. Enterprise Product Ownership (part 4)

*************************************

We started more than 3 years ago with basic and simple Scrum approach. Scrum definition of Product Owner:

The Product Owner is the one and only person responsible
for managing and controlling the Product Backlog. This is the
person who is officially responsible for the value of the work
done. This person maintains the Product Backlog and ensures
that it is visible to everyone. (Scrum Guide page 4)

This approach assumes a few vital fundamentals that are in place, otherwise we might will face problems:

1. Scrum team is in place: we have a ScrumMaster, PO and a team. Team should be crossfunctional end-to-end feature team. In my thinking this implies that enterprise level operative view is embedded within one team. In other words the whole value chain is realized with 5-7 persons and multiplied (if scaling is required) with additional teams that share the same approach.

2. Customer collaboration over contract negotiation. This is the fundamental from Agile Manifesto which is maybe the most important (and most often misused) when considering PO. In enterprise this means that there should not be separate Product Management and R&D organization. PO (as fully responsible of value of the work done) has the authority and responsibility to use all assets as he/she prioritizes. There is no role for R&D line organizations to decide what work is done by people or machinery. The traditional commitment game has disappeared. Unfortunately I have not seen or heard this being realized in any large organization. If this is not in place (as I have witnessed) -Scrum does not work. 

While we now seem to somehow understand these we do not have (or did not have) these fully in place. This created a lot of confusion and additional challenge in understanding how Agile is realized within Scrum context. A couple of examples.

Product Owner did not understand what is the level of technical detail he/she needs to go. This was partially due to missing authority on the business side -focus was put on the technical issues instead of business value. This was partially fixed with moving more responsibility of technical work to System level Communities, which were for developers (I will open up this more in part3 of this series)

System test was completely missing from the early User Stories and Epics. This resulted that work was only partially done within Scrum teams. This division also was visible also within Product Owner: “Done” features could not be delivered to customer before additional testing or configuration (outside Scrum teams) and this was not perceived as responsibility of PO.

Impediment handling was not sufficient. Only part of the organization was attending to the continuous improvement work withing Scrum context. A lean principle “see the whole” was missing and this resulted to sub-optimization.

To summarize: our organization was not able to adopt simplistic Scrum approach to make it work sufficiently. We might come back on these ideas when we learn how to implement more vital key fundamentals but initially our decision was to adapt. Our next approach was to introduce Scaled-Up Scrum (more on next part of this series).

-Henri

Posted in Agile Thinking, AgileTesting, Continuous Deployment, Framework, Leadership, Lean, Product Owner, Scrum | Tagged , , , , , , , , | 5 Comments

Collision with the classic school of change

Or “One (out of many) reasons why bottom-up changes faces friction”

I was attending a classic HR work shop going through the classic theories for change management including the classic change curve here at the big company. A lot to be discussed but here is one reflection I made during the session:

At the moment we see a bigger need for changes in our organizational culture where one cornerstone is to go from “command and control” towards “trust and transparency”.
That includes empower to people and teams, promoting changes and improvements coming “bottom-up” through the organization.  In hand with agile we have seen many “bottom-up” initiatives starting to happen long before management knows about them (good!).
What if we read the change curve theory literally, What happens then?

Here is a scenario:
Top management comes up with the idea to “go agile” and have all employees involved, empowered and driving the change.
(This is kind of typical that top management likes bottom-up changes as long as they (the top) initiates it)
Bottom-up movements starts and throws people down along the curve and some day they are through and on the re-orientation side. Next, middle management starts to understand there is a change going on and goes into denial and reaction phase. If managers are stuck in the view that organizations shall operate hierarchical, they will not realize they are a step after their employees but on the other hand a step before their managers.

In the classic change literature this picture is found.


Here I think we can see an extra friction. While employees tries to re-orientate, they have a management in denial or reaction phase. Not much support to get there! Even worse is that managers might assume the employees is on the wrong track as they, according to classic books, shall traverse the curve later.

Without some extra spark, challenging, enthusiasm, breaking of rules this might stall the change process quite some time, at least until management is catching up (and then it’s not a true bottom-up change anymore)

Conclusion: First to change is to get managers embrace and handle true bottom-up improvements

Conclusion2: Revise the classic curve of change and change theory for company where continues improvements and frequent changes is part of daily operations.

Cheers
Johan (Welund) Westerlund

Pictures: Make Change Work, Ulla Mogestad, 2000

Posted in Change, Leadership, Transformation, Uncategorized | Tagged , , , | 4 Comments

Reduce Risks or Increase Chances

This small thought was elaborated with some friends at a late summer night. Not sure if it has any greater meaning to life and work or if it just  a late night mumbo jumbo.
It’s possible it’s described before by other distinguished thinkers but let me share our thoughts.

In “the big company” there is lot of effort spent in risk management, risk analysis and risk reduction – what if we spend all that time and effort on increase our chances to succeed instead ? At first it might not sound like a big difference but perhaps it is, at least in attitude and mindset.

 Reducing risks makes you think of all the threats and things that might happen to prevent success for your project like “things being more complex than estimated”, “integration takes time before get it working”,  “critical deliveries not made in time”, “key resources are needed for other tasks”, etc. All with the focus to make the critical path under control. By this there is a built-in believe that there is one correct path to walk and the task is to find threats and remove obstacles while walking that path. An increase chance based approach would be to work on finding more than one critical path to success. It may turn out that such a mindset will increase our success rate.

Let’s look at a simplified metaphor:
Take an ordinary dice and assume a “6” is success of your project and 1 to 5 is failure where 1 is the most critical failure. A risk based approached would be to put in most effort on trying to remove the number 1. If you do your job well the 1 is gone and your chance for success is increased to 1 to 5. A chance based approached is to look at what is close to success, in this case a “5” and put all effort to make the 5 turn into a “6”. If you are doing this job well your chances for success is 2 to 6. Slightly better!

Dices in transformation
(Actual to make  the picture work the dice should turn into a 5-sided dice…)

What can this mean in our daily project work?
Is there a difference between the glass being half empty or half full?

This nightly session with some friends didn’t find any further answers…

Cheers
Johan (Welund) Westerlund
Thanks Fredrik Tystad and Andreas Pettersson for your contribution
Posted in Agile Thinking, Change, Leadership, Lean, Risk Management, Transformation | Leave a comment

Continuous Deployment – Going for brilliant products

Continuous Deployment starts to be a very popular buzz word and especially the lean start-up scene seems to be taking both the hype factor out of it as well as enjoying the benefits that CD offers.

All the major web services like Facebook, Twitter, Google, Flickr, WordPress, etc; they all utilize CD, even though everyone has their own adaptation of it, they all share the same principles: deploy small, deploy often, learn and react. This simplification already gives us a hint on what’s it all about, it’s not about a cool engineering practice, it’s about speeding up your delivery, boosting quality and it provides possibilities for large enterprises to gain start-up style agility.

The web services development suits well for fast paced continuous integration and deployment since it is a rather new industry that has optimal setup to support efficient software development as well as such  competitive and adaptive market where you need to be fast and responsive. (Does lean and agile ring a bell) The web based services can be seen as forerunners in Continuous Deployment but are they the only one’s who can benefit from it?

“We can’t do that since we are so complex and we need to verify that the product still works after upgrade and we need to train our personnel for the new functionality” This must be the most common excuse why continuous deployment is not viable to some product or company. But looking at the already mentioned big companies using CD,  they do work in an environment that expects them to be accessible all the time, extremely reactive to: fixing any faults found and exceeding the new requirements from customers. Now I’m puzzled, how come there is something so complex that it requires that you make only big bang integration and fix faults mostly in planned releases that drop in here and there with slow and steady pace?

It’s good to point one more big benefit into the list “why CD?”; with Continuous Deployment the integration effort is very different when compared to big bangs, you can do software deployments as part of your normal operations, not as a separate integration project that requires (at least) system and configuration updates as well as possible staff training. Not to even mention the lead times that this setup creates. Waste, some might say.

Looking from that angle going for going for small changes that are deployed often sounds something like, umm awesome?

Taking into account that this world still hasn’t gone black and white, we of course need to adapt our thinking to suit the field of industry and deeply understand the customer view. Maybe it’s not possible for everyone to deploy a new version of the system into live use every second but is the only option slow paced big bang approach?

Deploy small, deploy often. Learn, Adapt.

Go for brilliant products.

Posted in Agile Thinking, AgileTesting, All, CI, Continuous Deployment, Continuous Integration, Leadership, Lean, Transformation, Uncategorized | Tagged , , , | Leave a comment

Windmill Challenge

Don Quijote attacking the windmills (that he thinks are monsters) is used as a metaphor for something noble and brave for an individual. I often hear that being an agile advocate inside large organization can be something like this -maybe so. But on the other hand I have the privilege to work with brilliant people and when working together the windmills actually look pretty small. They are there, no doubt about it, but the initial challenge feels much smaller. There cannot be a situation when one is right and everyone else is wrong. This is something we all can leverage and feel more safe -we are definetly not alone!

What then can be seen as windmills inside a large corporation? I just found a good writing from Craig Larman, Bas Vodde and Tom Arbogast http://bit.ly/LVO6fL. This primer summarizes pretty well the real monsters inside traditional organization: like when your business is based on 10 years contracts with penalties, there is not much that lean and agile can help you with. If your value proposition is already contracted (with penalties) what there is left to iterate?

However agile adoption tends to spread. It takes over the next silo and starts to make changes in the peoples heads. This will take time, but if we just allow it to happen, it will make our life much easier. And please remember: There is nothing to lose but a lot to gain.

Posted in Agile Thinking, All, Change, Leadership, Lean, Transformation | Tagged , , , , , | 3 Comments