Friday, July 11, 2014

Agile maturity model = Shu-ha-ri?

SHU-HA-RI 

describes the stages of learning to mastery.


It is known that, when we learn or train in something, we pass through the stages of shuha, and ri. These stages are explained as follows. 

In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our brain created. We remain faithful to the forms with no deviation. 

Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded.

Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.

Learning Agile you also go though these phases and must respect the elements in the stage you are in and the stage the people you interact with is in before applying the agile mindset. There are many other maturity model (ex. Dreyfuss model)  but this Shu-Ha-Ri is the simplest and Leonardo da Vinici said "Simplicity is the ultimate sophistication" so lets stick to this for the time being.


Using Shu-Ha-Ri in agile
Understanding the variation of do agile or being agile by understanding the level of agile knowledge. I've taken a shot at what it would take to practice agile at the different ShuHaRi levels by focusing on the agile principles.



ShuHaRi is also describe by many agilists like Martin Fowler or Alistair Cockburn


Friday, January 24, 2014

STOOS!!!! - Pless you!

Stoos - What's that?

It's not a cold. It's a network discussion a paradigm change within leadership. Changing from "I telling you" towards "I ask and we do"

And yes, it's also a small Swiss city where the first initial meeting was held - and hereby the name Stoos


Thought from Ole Jepsen's interview at InfoQ regarding True Leadership using
David Marquet Leader-Leader model is in my opinion the essences of Stoos.

Changes to "Stoos" paradigm 


Going from "I - you" relation towards "You and I - We" relation. 

Three examples of shared responsibility.

Example 1 - "Priority?"

  • I
  • Ask
  • You
  • What's important and
  • You tell me and we make it happen

Example 2 - "Strategy?"
  • I or You deliver a vision
  • We decide what is important
  • We setup short term goal
  • together we do “whatever it takes” to move toward “it”.
Example 3 - "Delegation?"
  • Whoever chooses to join in are “the right people” / a knowing community / a network
  • through whose ongoing interactions “meaning” / what’s important / a direction
  • emerges over time, and
  • together we do “whatever it takes” to move toward “it”.

How is this different from today?

Many companies are working within the old paradigm where;

  • “I”/ with a mind / knowing / the leader (subject)
  • tell
  • “you” / with the “hands” / instrumental / the follower (object)
  • “what’s important”, and
  • you help me make it / “the plan” happen.

When to use Stoos?

When struggling for survivor this paradigm doesn't seem relevant. Here you properly prefer more forcing, commanding or persuading like dialog due to the way human brain works. 

Well, using Spiral Dynamic to determine when using Stoos is useful it would properly be within the upper levels like green, yellow and turquoise (level 6, 7 and 8). Here working together towards a goal would not be successful by forcing, commanding or persuading as the right approach would be more Stoos.


Stoos is not as big in Denmark as in Nederlands where gatherings and conferences are held like http://bit.ly/MjfVHq. The term is getting more and more understood and is soon becoming an important within the agile community. 

Sources



Friday, November 22, 2013

Product Owner! That's a stupid idea!

You need to leave the office to learn what you don’t know!!!! 

Go where the people you’re helping work.

I was thrilled attending Jeff Patton’s talk at Agile 2012 with the provoking title of ”Why Product Owner is a stupid idea” it seemed to be a promising talk.

Jeff is one of those people who have important stuff on his mind and every time I have attended one of his talks it has been very interesting to listen to. So I was shock of this strike at the Scrum and Agile concept of being a Product Owner or Product Champion. Why the hell….?

At that time I just had used an year implementing 5 teams with a dedicated P.O. which seemed to work at e-conomic J I was proud as the new P.O. superman started to perform and everybody knew where to go with their problems.  Yet, the P.O.’s were soon over worked and becoming another proxy for the business. 
Not seeing this at once must have been my excitement of having implemented an agile way of working .
The challenges with P.O.’s are many and now we had set a new limit for scalability which was the capacity of these new supermen. With the best intention we implemented a P.O. structure and what we really did (subconsciously) was to set up a RACI. It is no different that classical project management. You might ask what is wrong with clear responsibility?



One of Jeff Patterns argument was that “Safety is not success” the output is, the value we are able to provide for the customers are the success – together! Together as a team, together as one business and working together with the customers. Trust and honesty. I agree with Jeff Pattern and a clear a priori responsibility definition doesn't provide agility. Instead we have set up a new set of the Blame game


Where is the empathy, where is the understanding of the human interaction, where is the shared vision of wanting to change for the better? Working together towards the shared goal as a team in close collaboration with the customers is clearly more attractive and more responsible!  

Having ONE product Owner is not scalable! What happens when this person leaves the company, becomes ill or need for his/her services are too many to for fill?  Why is it only one person that is to understand the business, to talk with the customer, to see how the customers every day pain in situ? How should we get empathy behavior if we don’t meet face-to-face?  

One of the twelve principles behind the agile manifesto says that "Business people and developers must work together daily throughout the project" while many interpretations of the P.O. has indeed shielded the business away from the developers now information is delivered by this proxy the Product Owner. It doesn't have to be this way that the P.O. act as a shield but many many many companies I've talked to has implemented this anti-pattern that the P.O. is become Proxy, the superman, the one representing the business.


What to do?
I believe that not many companies are at this position of being agile even though Jeff Pattern is working with companies like snagajob.com, Nordstrom, edmunds.com and like the the rest of us are working in companies just started or on the way towards more agility.

So let’s play. Write any comment on how you think we can get closer to our customers? We have so many methods to proxy for this like personae, empathy map, User experience mapping, journey map, Stakeholder mapping, Story boards,  user stories, Story mapping and more but no of these beats or substitutes the learning and understanding when seeing, feeling and sharing pains in an everyday working day.


You need to leave the office to learn what you don’t know!!!! 

Go where the people you’re helping work.


Friday, November 8, 2013

Scrum updated (2013) including my humble experience as an add-on.

I’ve written a summery post about Scrum update 2013 including my experience and advice. It’s been a while since I ever have posted anything about Scrum but two events have inspired me to do so. First I went to a private dinner with Jeff Sutherland last year since he is a friend of Systematic. I discovered that once getting to know Jeff he is truly an amazing man and he has had lot of experience! Then this year I attended his talk or Q&A at Agile 2013 Conference regarding the Scrum 2013 update where Jeff just without prep answered question about the update that Kenn Schwaber and Jeff just published. Then I thought that my own experience with scrum is similar but also kind of different and want to share this experience with you. So here goes J

Scrum itself is based on 3 pillars and 2 of them are Inspection and Adaptation (the last one is Transparency). Now learning about scrum is not what this post is about but below I’ve drafted out the 6 changes made to the Scrum 2011 version into this Scrum 2013 version and in addition to this I’ve ADD MY EXPERIENCE as a comment which is experience (empiric learning) and offered as an add-on for you to use J

The 6 areas that are updated in Scrum 2013
1. Artifact Transparency
2. Sprint Planning / goal
3. Product Backlog
4. Time boxed events
5. Daily scrum or planning event
6. Value

1. Artifact Transparency
If thing is not visualized bad decisions can be made, so make your artifacts visible like Product Backlog, Scrumboard (sprint backlog), Burndown Chart, Release Board, User stories, Test scenarios , Performance analysis and more or you increase your risks and value may diminish!

ADD MY EXPERIENCE: Transparency of how clear the scope is for the next sprint is a great metric to measure and sharpen your “Readyness” of the team’s ability to secure grooming is done before sprint start.

ADD MY EXPERIENCE: All teams should be using posters, paper on the wall for the scrumboard and a product backlog on the wall too. It should be tangible so we can fell the way we work, standing up, moving posters with our own hands and prioritizing the backlog by moving posters up and down. In fact, everything should be on the wall and nothing should be in an application. Well, I know that this is not going to happen due to several facts, like small space, extended / dispersed teams or like. If possible do like above – if not, try to make as much visible by setting up monitors that are showing the stats places where everybody sees it, in the hall way or like.

2. Sprint Planning / goal
Use as much time as you need and focus on the sprint goal. This is often 2 hour per week your sprint is. So a 2 weeks Sprint Planning meeting should be 4 hours maximum.
The target for the sprint planning is to set up “The sprint goal” which the all tasks should be the fundament for.  

ADD MY EXPERIENCE: As we in the end of the Planning meeting forecast the items of the sprint backlog II strongly suggest to follow the recommendation provided by the Scrum Guide “Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.”. I believe decomposing the User stories into tasks of 1 day or less forces cognitive thinking about the forthcoming  work and flosses out risks (the subconscious known risks which is yet not spoken out). This will affect the teams view on the “Sprint Readness” before commitment to sprint scope.

3. Product Backlog
“The Product Backlog is refined rather than groomed. The refined Product Backlog items are transparent, well enough understood and granular enough to be input for the Sprint Planning and for selection for the Sprint. Product Backlog items with this transparency are called “Ready.” Ready and Done are two states that reinforce transparency.”

ADD MY EXPERIENCE: The difference between “refined” vs. “Groomed” I do not understand so I like to explain what my experience is and I’ll call it Grooming. Doing Grooming in two steps as a pre-burning event is very powerful.

A.) P.O. Grooming :
First of all, a user story or a creative process is running within the product development process which the scrum framework doesn’t include (which is a good thing). Well the business need to groom any new idea and as it evolves this needs to be written into a user story and elaborated (I call this P.O. grooming or Business grooming). Now the P.O. is ready to prioritize the continuously evolving product backlog and now the developers are add (a developer could be taken into advice earlier).

B.) Technical Grooming:
Often the developers meets the product backlog items for the first time at a Sprint planning event, but I like to schedule a 2 hours of technical grooming session for each week of sprint as a pre-burn to the sprint planning. This has some advantages and few disadvantages.
One of the advantages is that developers are being presented of the product backlog items before sprint planning they are able to have time to think about how to work out the technical specification. This fits at least 2/3 of all developers personality they rather think before speaking out they mind of something new they just has been presented to (Introverts).




C.) Sub-Grooming:
Another advantage is the ability to do sub-grooming. Sub-grooming is done by 1 (max. 2) developer working with a POC or just investigating a technical hunch to solve an issue. The sub-grooming result is presented at technical grooming session for the rest of the team. Now it is possible to do experiments and investigation before deciding on the sprint planning meeting what to include in the scope. This will reduce the technical risk of these items. 

Doing technical grooming and sub-grooming as a pre-burn to the Sprint Planning meeting reduces meeting time of the Sprint Planning Meeting” as all the team need to focus on is the sprint goal (presented by the P.O. as a business goal) and the work the team will committing to for reaching this Sprint goal. Now it there are less variables at the meeting and it is easier to secure that our scope is “Sprint Readiness” = 100%.

Well, the disadvantage I can see is that we now have the possibility of task switching as we have to plan and execute one extra meeting a week. True. I just like to add that the price of not having a ready sprints scope is mostly not meeting the sprint goal – so I still recommend this way of working because I’ll seen it work in many different teams and companies.
  
4. Time boxed events
All meetings are time-boxed and executed in a manner that the purpose of these events are meet within the time-box as we are preventing waste.

ADD MY EXPERIENCE: Time-box with having the pomodora technic in mind. I suggest the following time-boxing
  • Sprint durance 2 weeks (first day Wednesday week 1. until Tuesday week 2.)
  • Daily scrum 15 min. every day and it is best when done in the morning between 9.00 am and 9.30 am
  • Sprint planning 1 hour Wednesday morning and followed by a Daily stand-up
  • Technical grooming in 2 hours once a week (Friday morning or afternoon is good choices)
  • P.O. Grooming is not a meeting within the team but P.O. Grooming involving developer feedback should be done with in max of 2 times 25 min with a 5 min. break (55 min.) once in a sprint.
  • Sprint review in 30 min. divided into 15 min. for demo and 15 min. of feedback from the guests. It must be held Tuesday just before lunch or just after lunch in week 2.
  • Retrospective 2 hours (see my blog on how to conduct retrospectives)
Other meetings that the corporation needs the team to attend to are often forgotten to include in team planning!
  • Daily project brief max 10 min.
  • Weekly department brief max 30 min.
  • Monthly company brief max 1 hour
  • Attending courses and conferences which be subtracted from the sprint velocit

The next 4 bullets are difficult to plan but experience helps a bit and experience within the team helps a lot. Earlier sprints preforms knowledge which you can apply common sense and reserve time for these unexpected event within the next sprint as having time-box “tasks” or “posters” with the time of ½ or 1 days’ work that can be used for such unplanned events. Remember to use different colors for the different type of tasks on the board so you easily flag out these unplanned events – helping transparency.
  • Attending job interviews is a joker but it not very often this is the case
  • Attending workshops with creative, business or architectural ones
  • Support other projects
  • Support operations


Questions still need answers!
  • What to do in virtual teams?

If we don’t meet on a regular basis at the coffee machine or in the cantina how can we get to know each other and get empathy, understanding and trust?

  • How to handle teams with different personalities and/or cultures?

Like Latin America girls often need to small talk like 5-10 min. in the start of the meeting before they will decide anything. Accountants hates small talk! Sales people is only doing small talk! Introverts is not participating in a workshop and so forth. These different personalities and cultures makes it hard to set up a template for meetings and workshops removing all “Waste”. You need to take these aspects into account.

I like to hear your comments on these questions? What are your experience?

5. Daily scrum as a daily planning event
The team must Re-enforcing the Daily Scrum as the daily planning event. Don’t use the daily scrum for status rapport.   Therefore the questions are changed.
a. What did I do yesterday that helped the Development Team meet the Sprint Goal?
b. What will I do today to help the Development Team meet the Sprint Goal?
c. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

ADD MY EXPERIENCE: I like the questions to be different prioritized. First things first. What is the most important thing to know?
The 3 daily questions:
A. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
                B. What will I do today to help the Development Team meet the Sprint Goal?
C. What did I do to meet the team to reach the team sprint goal? (And If I didn’t do anything yesterday to help the Development Team meet the Sprint Goal – don’t share)

6. Value
Focus on the value that the team delivers

ADD MY EXPERIENCE:
Value provided for the users is absolute the only thing that matters. No matter how fast your database run, how well your test are executed or how fast the code is transferred over the wire to the customer matters at all. What matters is the customer experience and the value the Customer gain from the solution. That's way we sometimes have to compromise great craftsmanship for reaching a window of opportunity. I really like to set up the plan so that we deliver smaller trunks and then deliver often.

At e-conomic we made a team deliver improvements to the running application once every 14 days (called Marked Packets) which increased the value for our Customers incrementally - This is truly a great way to work due to all the positive feedback from the customers and the ability to adapt to any wishes spoken. 


Sources
Kenn Schwaber and Jeff Sutherland present this new updated guide

At Agile 2013 in Nashville Jeff Sutherland answer questions regarding this new updated guide. I've taped most of the session and share it on Google Drive. Sorry about the sound quality I hope you can understand it anyway. It was taped in a big conference hall with some kind of echo.

1. https://drive.google.com/file/d/0By7RGeHx3vR9NXhVSXA4RnVVZVU/edit?usp=sharing
2. https://drive.google.com/file/d/0By7RGeHx3vR9RkZ6Y3ZUQWNLcmM/edit?usp=sharing
3. https://drive.google.com/file/d/0By7RGeHx3vR9a1hXcVNEaTB3Q2c/edit?usp=sharing
4. https://drive.google.com/file/d/0By7RGeHx3vR9dHE4ZVlTc056UFk/edit?usp=sharing
5. https://drive.google.com/file/d/0By7RGeHx3vR9eHlZQzV2MUtmU2c/edit?usp=sharing

Wednesday, October 23, 2013

Slicing the elephant into Carpaccio.... is that even legal?

Learn fast

Don’t “fail often and fast” but “learn fast” should be our focus and what we communicate. Customers don’t like to hear you are planning to fail and even so you what to do it fast! Alistair Cockburn thinks that reducing risk and I tend to agree. Getting knowledge of all the uncertainties which of many there are in the category of the unknown  unknown.



Jeff Pattern argues that “You need to leave the office to learn what you don’t know!!!! Go where the people you’re helping work.” Well, Alistair argues that the people at the jobs don’t know that they need and don’t have time to figure it out, so you will only be in their way.

I believe that you should go to GEMBA (go see the forest) and you’ll learn more than staying home but don’t leave it with that. If possible get collaboration between developers and business people at a minimum of organizing daily coffee in a relaxed environment for giving a change of making an informal room for sharing knowledge.
Reality is often not agile friendly! Using an indicator of how agile friendly a business is will help you making decisions. Just set a scale of 1 to 5 where 5 if like pivotal labs – really agile in the hole organization and a 1 for a an public organization that are extremely political and where trust is something you use to gain personal advancement in their carrier. 


Coming back to Learning fast surely potentially helps covering Risks like business risk, people related risks, Technical risk and Cost schedule risk, but it’s not given by itself. You need to slice it. Slice it into the right small Carpaccio slices though the 7 layer architecture (vertical) and NOT horizontal.  

Coming back to teams that are Learning fast surely helps mitigating like business risk, people related risks, Technical risk or/and Cost schedule risk, but it’s not given by itself. You need to slice it. Slice it into the right small Carpaccio slices though the 7 layer architecture (vertical) and NOT horizontal.   

So Alistair Cockburn did a whole three hour exercise learning to slice the Carpaccio. Surly everybody knows how to eat an elephant, which is to eat it in pieces.

BUT slicing the elephant into Carpaccio is that even legal? Well as long as we don’t loses or job or go to jail it’s just what we as a fast-learning-risk-reducing-super-professional-CMMI 5-software producing company NEED to do.

Enabling slicing incremental business value part into less than a hour’s work is very provoking as we are many who strive to get a user story into the max of 3-5 days and every day’s work described into at a max of a day’s work and even this is hard. How can we produce Value in less than an hour? Why is that so hard? What is preventing me of doing this? Resistance at my team, misunderstanding of the agile  concepts, misinformed agilist, lazy people  or is it just due our lack of knowing  that this is possible. Now we know. Now we know!

Check out Alistair Cockburn’s blog where you’ll find the Carpaccio slicing exercise.

----------------
If you don’t know Alistair Cockburn – you must know this! He is the one how rented the ski cottage where the agile manifesto was written. He is in the agile movement almost from the start and invented the agile way of working called “Crystal Clear”. He has been in the inner circle of the agile many years and an often speaker at agile conferences. He has an agile angle that is worth listen to.

Today he was a guest at Systematic as a speaker. I’ve concluded my learning of today. 

Friday, October 11, 2013

Alistair Cockburn, are you mad?

Today in a meeting with Alistair Corkburn he pointed out that retrospectives in a scrum team are not nearly radical enough. If the teams haven’t tried to quit Scrum, remove the Scrum Master or suggested a new organizational change they are stilled bound by the invisible rules set up by them self.
All the rules we think there is applied in our everyday interaction with customers, colleagues, management or our life itself are often rules we apply upon our self. Alistair states that we must challenge these rules as long it doesn’t get us in jail or fired.

We optimize our teams though retrospectives by the max of 10% as we go along sprint after spring while it could be magnitudes instead.
We really need to challenge our boundaries hard and then dear to make the changes which could including removing people, methods, processes or other really impediments – not just this sub-optimization. 
I believe that that we should go to work in the morning with the attitude that we might not have a job when we come home at night - at least we should not be afraid to say what we think and mean. This is radical and as I’m getting older I tend to loosen up on this principle J  


Let’s challenge our retrospective, let’s be inventive, lets come up with new ideas and might they be radical!!!!