The Blog
Looking for Scrum training in Finland?
published February 2, 2012
Well, you came to the right place. Tomorrow, February 3rd, we are releasing Finnish Scrum guide 2011 and thus it would be a great time for you to gain more Scrum knowledge. I provide following courses:
Professional Scrum Foundations
Scrum Teams succeed best with a solid foundation and this 2 day course prepares students to begin effectively using Scrum immediately. The Scrum framework, mechanics, and roles of Scrum are emphasized with emphasis on practical application. This course is the perfect introduction to Scrum for anyone new to the framework. Whether your team needs a flawless Scrum launch or needs to reboot a struggling Scrum implementation, this class lays the foundation for an effective Scrum team. This course lays the foundation of knowledge needed for other, more advanced training such as Professional Product Owner and Professional Scrum Master.
Professional Scrum Master
The Professional Scrum Master program includes a course, an assessment, and a certification. The Professional Scrum Master course is the first significant update of the Certified ScrumMaster (CSM) course that Ken Schwaber first created in 2002. The Professional Scrum Master course covers Scrum basics, including the framework, mechanics, and roles of Scrum, but it also teaches how to use Scrum to optimize value, productivity, and the total cost of ownership of software products. The program includes two levels of assessment and certification.
Source:
Scrum.org Program overviews.
Interested? Drop me a message!
Agile vs. Lean Six Sigma
published November 2, 2011
Are these two related in any way? Is Lean Six Sigma some ancient process improvement method that has nothing to do with software development? Now that I’ve covered Kanban vs. Scrum I thought it would be a time to compare Agile to Lean Six Sigma.
Five domains of system categorization
Before we dig into Lean Six Sigma I should clarify some terms that will be used. A leader’s framework for decision making defines basics for Cynefin Framework, which is available at Cognitive Edge. This sense-making framework defines five categories for any system: simple, complicated, complex, chaotic, and disorder. Basically, it says that work in different domains should be managed differently. The fastest way to get a grasp of the ideas is to watch this video:
What is Lean Six Sigma?
As most of you already know what Agile software development is all about, I won’t go into that. However, Lean Six Sigma is something that the majority of people have no idea of. Some people see Lean Six Sigma as a desperate attempt to combine the old-fashioned scientific Six Sigma method to the Lean method as that is now the hot topic. Lean was derived from Toyota Production System and Six Sigma has nothing to do with that, right? Not so fast.
Six Sigma method was originally developed by Motorola in the 1970s and it is a systematic way of improving processes. Later, Lean concepts were added and Lean Six Sigma was born. You can read the full history e.g. here. Jeff Liker comments on Lean vs. Six Sigma like this:
If a company that does not have a history of process improvement has started with lean and used lean tools to work on flow issues, setting up cells and supermarkets, will this be enough? The answer is a resounding no. All they have done is set the stage for identifying problems. They need a problem solving method. Some companies are using six sigma in this way and that is fine. The serious ones learn that the green belt training given to the work groups will solve the large majority of problems. But then you still need to evolve over time into other aspects of the system–team leader role, andon, standardized work, visual management, hoshin kanri, etc. I say evolve because it is a long-term process in which you try something, make mistakes, reflect, adjust, and then as you get good at that you add more to begin to build a system. The underlying framework was also taught by Deming and it is PDCA.
Lean Six Sigma defines an improvement process, tools, and roles that should be present in a Lean Six Sigma project. I think that role belt system (black belt, green belt, etc.) part is somewhat comical and can actually hinder Sig Sigma adoption in organizations. However, the theory is that you can take any process (sales process, production of goods, etc.), check how much defects it’s currently producing, and initiate an improvement project to decrease the defects thus increasing your company’s value. Lean Six Sigma defines 5 phases that improvement project should go through:
Define: What is the problem, how it should be improved, and how the improvement should be seen?
Measure: Measure the process using historical and current data.
Analyze: Analyze the gathered data to find insights.
Improve: Improve the process by finding key factors of the process.
Control: Ensure that modifications are used and deviations from the target are corrected before they result in defects.
These phases form a DMAIC acronym that simply states the order of process improvement activities. In addition to the phases, Lean Six Sigma defines a whole host of tools to be used in every phase. The tools are very much statistical such as ANOVA and Regression analysis. This is basically what you can read in Wikipedia but does not answer to the question: “What is a Lean Six Sigma project like in practice?”.
A manufacturing Lean Six Sigma sample
Your company manufactures tables. You have a problem that 30% of the tables’ surfaces are curved and have to be scrapped. This costs you annually 300.000€. Your employees all have some ideas how to improve the process and these “improvements” have been tried out. However, the long term scrap average remains at 30%. You start digging into the problem and find out that over 200 variables have some influence over the end product. You are wondering whether there are few vital variables and if optimal levels for these could be found, the scrap would be dramatically reduced. As it turns out, there usually is. Your challenge is to find these.
You start reducing the number of variables, you do this by guessing, interviewing experts, and using tools suchs as 5 whys and FMEA. You gather data from the current production and use historical data to find patterns. Usually historical data is completely useless as causal relationship is almost impossible to deduct from it. However, by continuing this guesswork, you can reduce the number of variables to about 10. You are quite confident that some combination of these variables will produce the result you are after. How do you test all combinations of the variables? One at a time? No, you will design an experiment. A factorial experiment. You will make a mathematically clever test plan which allows you to change multiple variables at a time and be able to componentize the effects of each variable using statistical software such as Minitab. You can only run about 40 tests and gather information about very large number of combinations. These tests reveal you that variable A should be set to 10.5, variable B should be set to 3232. You make modifications to the production line and check the results. Defect rate drops to 5%. Great! How long did this take? From weeks to months, it depends on your business.
Err… I am not manufacturing tables.
Right. Now it gets tricky. Six Sigma sees people producing software as a process, and so it could be improved. Agile people respond that they are producing a once-in-a-lifetime solution in a complex domain which requires innovation and creativity, you cannot use that statistical stuff in here. I think both camps are partially right. Why? Please, read on.
Lean concepts fit better together with Agile. Drive down the waste and you are improving. But a Six Sigma approach to improve e.g. Scrum team’s performance would go something like so:
1) Come up with potential process variables that could cause number of defects to reduce. E.g. unit test coverage, ATDD test coverage, and usage of pair programming.
2) Design an experiment where different features will get done using different combination of values for selected variables. A small sample of a test plan could be:
-unit test coverage 100%, ATDD test coverage 0%, no pair programming
-unit test coverage 0%, ATDD test coverage 100%, pair programming…
3) Execute an experiment and find out that 80% of defects could be reduced by pair programming and keeping unit test coverage at 100%. ATDD test coverage has little effect on the end results (Note that I do not know if this is the case, this is just an example!)
The problem is that I can already sense how a Scrum team would react to this suggestion. Are you [insert your favorite word] kidding? “Trust me, I am a Lean Six Sigma Black Belt” will not help starting the experiment either.
Lean Six Sigma works with a Taylorist mindset and tries to find causal relationship between an action and an output. It is a neat way of working when causal relationship can be detected in a complicated domain but falls short when working with complexity. There is nothing wrong with experimentation per se, but if the approach is completely out of the group’s norms there is a slim chance to get the experiment done. Statistical stuff in Six Sigma is quite hard and takes time to learn. If the team cannot fully understand what the statistics behind the method are, acceptance of experimentation approach might not happen.
Romanticized complexity
Not all people agree that software development is all complex. I ran into an article about this stuff. Joseph Pelrine says:
Unfortunately, the typical Agilist perception of complexity is not quite aligned with any of the main scientific definitions of the term. Agile literature abounds with romanticised, subjective interpretations of terms such as complexity, self-organisation, emergence, which can only be understood by remembering that ‘a little knowledge is often a dangerous thing.
He continues the analysis of software projects and state that 38.5% of work is in the complex domain. Many people are saying that “Software project is complex” but Cognitive Edge blog claims:
The activities tend to be weighted more to the complicated and complex domains, with activities related to the coding aspect of software development landing in the complicated (or sometimes simple) domain, and activities associated with project management landing in the complex (sometimes chaotic) domain.
Finally:
Software development can benefit by being treated as a complex domain (and not an ordered one), and taking advantage of the toolbox of social complexity, namely the Cynefin method. The field (as well as many other fields of human endeavour) would benefit even more from a multi-ontological approach, understanding that there are multiple domains involved, taking the best techniques for the various domains, and combining them in an appropriate and flexible manner. This multi-ontological approach would also go a long way towards resolving the infighting and bickering now taking place between the “Agile” and “Lean” communities.
Of course he is boosting Cynefin method, but I am fine with that. I am also aware of “sick stigma” pet name that is used by Dave Snowden, which is actually pretty funny. Anyways, I see no point of using pure Six Sigma when dealing with complex domain. However, for some complicated problems method contains useful stuff.
Understanding variation, measurement and multivariate experiments
For me, these three were the most important aspects that I learned in a Lean Six Sigma Black Belt training. Firstly, by knowing if some variation is random (that is inherently present in all processes) or a special cause is a starting point when improving any process. If decisions are made based on random variation, improvement is headed to a dead end. Secondly, all measurement contains error and if you don’t know how much error your measurement system is causing, you are once a again making wrong decisions. Take a Scrum team’s velocity for an example. If the velocity is increasing sprint by sprint, it doesn’t necessarily mean that team is actually improving. “Improvement” could be caused by the measurement error when team changes how it estimates work. Thirdly, even though multivariate experiments do not fit neatly in to the software development process, they can be used to gain better understanding of a service or a product the team is building. Google Website Optimizer has multivariate testing tools available and Lean Startup movement is advocating usage of experiments. “The scientific method”, as Lean Six Sigma calls itself, has something that is usable also in a software product. Our Lean Six Sigma course instructor said that Lean Sigma Sigma could be seen as design of experiments on steroids, which I completely agree with.
During this week I visited The division of Pharmaceutical Technology to get more insights how Design of Experiments are used in pharmaceutical research. Problem in Finland seems to be that there are only few organizations that are actually teaching Design of Experiments. All-in-all, I try look beyond flame wars and to learn as much as I possibly can from different disciplines. It’s like in MMA:
Since the late 1990s both strikers and grapplers have been successful at MMA though it is rare to see any fighter who is not schooled in both striking and grappling arts reach the highest levels of competition.
Not the best metaphor but you get the point.
I have heard multiple times that creativity needs variation. Without it, creativity is diminished. I understand what people are saying and agree with it but I do not think it is quite this simple. It is not sufficient for an organization to just add variation to development process and collect the innovative fruits. Organization must learn to see patterns emerging in complex domain and have skills to productize them. Unfortunately, variation in many software projects is only seen by the customer in form of bugs and low quality. This has nothing to do with new innovations.
Lean Six Sigma criticism
Even though the method has some interesting tools, its approach to management feels somewhat outdated. Improvement process is driven by black belts that solve (at least in theory) organization’s problems one by one thus increasing organization’s value. Of course stupid workers are only in the way of genius black belts. The problem is that after improvement has been “installed” and black belts leave, workers can return to old ways of working, because they didn’t own the new solution in the first place. Especially in the knowledge work, team must take ownership of its problems and appropriate solutions. I feel that the whole black belt system does not work with Scrum because there should not be specialized titles in the first place. The team should be cross-functional, it should have all the skills needed to turn a backlog into a working solution and not rely on outsiders. Experiments should be owned by the whole team, not one person. Of course, then you encounter the problem that in Finland you have a very small chance of finding anyone who can actually design experiments, should you need one.
One could also state that Six Sigma did not invent Design of Experiments and that is the most valuable part of the whole method. If its management style is not suitable for complex domain, what is left?
Conclusion
Are Agile and Lean Six Sigma friends or foes? Are they compatible? They deal with different problems. Agile is suited for complex work, Lean Six Sigma might be usable in simple and complicated domains. Experimentation and probing mindset is useful in both domains. What I intend to do is to bring understanding of variation and design of experiments as tools for Agile software teams.
Additional Material
A Podcast on complexity by Dave Snowden
Reflections on Kanban vs. Scrum development
published June 23, 2011
Done and done! 1,5 years of hard work at National Land Survey is over. What a great project! This post will be on my personal findings about Scrum team transition to Kanban. What worked and what not? Moreover, I will try to analyze the failures we made and to come up with some solutions. Let’s get started!
Background
4 person development team was formed about 1,5 years ago. Team members were selected based on a cv, a hourly fee, psychological tests, and an interview. Two people knew each other from earlier project, but everyone else were complete strangers. National Land Survey’s “project team” consisted of Product Owner / project manager and about 8 subject-matter experts. Product owner had no previous experience on Scrum but he had been coached on Scrum prior to kick-off. Team chose me to work as a Scrum Master.
We started Scrum by the book. Two week iterations, Definition of Done, retrospectives, you name it. Some of our initial DoD agreements did not materialize immediately but got better while team learned to know each other. Basically steps that team went through in terms of Scrum implementation improvements were:
- Scrum by the book, velocity, definition of done
- Unit testing
- Swarming
- Continuous integration
- Automated UI tests
- No Monday sprint plannings
- Team member cross testing
- Process waste visualization
Team does not jell immediately and this takes time. Even though I knew all these things would be nice and even mandatory to have in place, you should not force them on a team if it is not ready. In addition, team felt that it had to make progress with features and team’s process improvements would have to be made in small steps. I feel that every team will have to discover their own process and you cannot copy-paste team culture. Therefore, first important rule for organizations:
Do not break well functioning teams. If possible, try to move them together to a next project.
Hmm, what did Jurgen say?
In Turku Agile day I listened to Jurgen Appelo talking about team’s emergent goals. Well working team will come up with its own goals in addition to those set by the Product Owner. First of all, it is important to be aware of this behavior but also to encourage team to find their own way. When well functioning team is torn down, a new team will start formation process from “lower level” (Tuckman). If team’s emergent goal had been a beneficial one, it is also lost.
Group prototype
Once group starts to work together it begins to form a group prototype. This prototype represents “us” and it affects team’s self-image. If prototype is “energetic and responsible” you are more likely to get good results than when prototype is a “sloth”. This whole prototype thing is actually really interesting as it also means that those who are prototypically central become highly influential. Check out this nice book about the subject. In short, well functioning team is a gem. Try not to break it.
Please, I am busy, do not get side tracked
Ok, back to year 2011. About three months ago we wanted to try out Kanban. Team had been doing Scrum over a year, solution was in production, and now team had trouble with “expedite” type of work. This work that had to be taken care of right away was mostly production maintenance and occasionally some bug fixing. Team (and PO) felt that it could not wait for two weeks just to fit these expedites into a sprint. Furthermore, team began to encounter stories that were really difficult to estimate. “This could be a 1 or a 10, it depends on x”. Team felt that estimation of these tasks was waste because they had to be made anyway. Downside of this of course was the fact that when some story was ten times bigger than originally estimated, sprint goal was pretty much nullified. In addition, team had challenges with work that had to be stopped because sprint was over. This caused situations where everyone knew that a feature needed an improvement but because there was not enough time to do it, team decided to move improvements to next sprint. This is somewhat wasteful because it would be nice to completely finish a feature team is working on if everyone agrees that it lacks some key functionality. Why move work in to the future? “Because we do not have time right now”. This lead us suggesting the use of Kanban to PO. Luckily, he agreed.
After three months of development and 4 version later, our board looked like this:
(click to enlarge)
Development team’s Kanban process went like so:
Development team used the Kanban board, “project team” did not. Product backlog was still maintained by the PO and stories were estimated in product backlog like in Scrum. Sprint plannings were replaced with “pull planning”. When “selected” stage had room, PO chose next tasks on to the board. Once “Analysis” stage had space development team broke user stories into tasks like in sprint planning. The difference was that these planning sessions were much shorter than with Scrum as usually only one story had to be analyzed. Team had 3 implementation lanes. When there were empty slots, story was moved onto the “development” stage. Then, slowly tasks moved across implementation and once everything was coded, tested and ready, story was deployed to “staging” environment and PO was notified. Next, PO and project team verified that everything was OK after which story was scheduled to a release. One lane was reserved for expedites. Plain and simple! Did that work? Well, that’s a good question.
Start with positive, what worked?
Team’s lead time was painfully visible and pressure to deploy increased as post-its kept piling up. Our lead time clock was started when user story was placed to the “selected” stage. Clock was stopped when feature was deployed to production. Lead time was measured in calendar days. We noticed improvements in lead time, partly because now PO was more concerned about it. I think this is in line with Lean promises that you get process modifications just by visualizing it.
Lead time is very easy to track with Kanban and in our case lead time was reduced.
In picture below you can see lead time distributions of 82 stories.
In this second picture, an individual moving range chart has been created and it looks pretty steady around 11,5 days. There are some special causes that were caused by “clustering” etc.
In third picture, I have created a boxplot to see how lead time varied between releases.
Based on these images, I would say team’s process was pretty stable. Was this data usable or not? Theory is that once we know our average lead time and standard deviation we can establish a SLA. Then organization can order features and be somewhat confident that it will get them when needed. Problem with this logic is that in our case organization was not particularly interested in this stuff. They were more interested in release level information and Scrum style velocity information was enough for them. That being said, in some other context this could be vital information.
So, what else? Benefits also included the fact that the team members were more aware about the status of a story. “Is this already deployed to test?” The board told you.
Work was nicely organized as everyone in the team could see progress on the board
Also, team’s initial concern about expedite work worked out pretty well. But does this encourage towards “could you fix this for me quickly” –type of behavior that is the one main thing we are trying to avoid with Scrum? I think so.
Team was very responsive to expedites. But this is not necessary a good thing.
What did not work as advertised?
It was pretty big surprise that PO actually felt that visibility to work was lower than it had been with Scrum. Once we thought about this it was pretty clear why. We had thought that informal meetings and a Kanban board would keep PO up to date on progress. It did not. In Scrum, we spent 15-20% of our time in Scrum “meetings” that also served as a way to keep everyone on track. That being said, this is not a fault in Kanban but came out of our work.
PO felt that visibility to work with our Kanban implementation was lower compared to Scrum.
One of the biggest “problems” was caused by the lack of a timebox. We had no predefined release cadence (maybe we should have), nor had we cadence for demos. But the problem was not only about cadence, it was also about the lack of commitment and “positive pressure”. In Scrum, timeboxed sprint will foster positive buzz as the team will not want to look stupid in demo. I felt that Kanban was lacking this energy.
Lack of commitments caused positive buzz to disappear.
Daily stand-ups where done in front of the Kanban board. Instead of asking what team members did and will do next, we focused on tasks. This created two problems. I think it decreased team member commitment and also caused team to focus on tasks instead of each others. Difference may be subtle but I felt that the team was more present in Daily Scrums and concentrated more to each others with Scrum.
Daily stand-ups were not as focused as they were in Scrum.
We held review when the team or PO “felt like it”. Usually at this point new features were already deployed to production and everyone had already tried them. This somewhat took the edge away from reviews.
Reviews were not as exciting as they were in Scrum.
What was really difficult?
It was not uncommon that one or more tasks were blocked by some external factor. We encountered situations where all free slots were taken and 50% of tasks were blocked. Often it was the case that none of us nor PO could do anything to speed up blocking issue. What to do then? We could increase WIP limits or try to proactively work with upcoming blockers. We tried both ways even though you should not continuously tinker with WIP limits.
Our initial WIP limits were too small and we had to increase them later.
Mistakes, mistakes, mistakes
It is obvious that we made many Kanban rookie mistakes and David Anderson probably would not give us Professional Kanban Master Certification. Anyways, Kanban by stripping down Scrum did not produce results we had hoped. I feel that Scrum team can benefit from Kanban type work visualization. However Kanban as a method, in my opinion, needs some structure. There was a nice tweet by Henrik Kniber:
Kanban teams rediscovering value of basic Scrum practices such as sprint reviews & backlog workshops
And I agree. “Kanban bible” recommends release cadences but it does not mandate where daily meetings should be held, how to inform your stakeholders nor does the book require you to get rid of developer commitments. Basically all the things that did not work was our own fault. In that sense Kanban is pretty advanced method because you really have to understand implications it has to psychology, team culture, and visibility. It definitely is easier to introduce Kanban to a company than to do a full scale Scrum transition. “Just do as you always have done, but use this board”. But will this actually change anything?
In overall, Scrum or not, organizations in Finland are in great need of full value stream visualization. It is not only about the development team. Value stream should be more visible in business side also. Then full concept to cash lead time would be very interesting.
Finally, you can also say that we created local optima with our Kanban and our lead time calculations should have included product backlog as it is the real inventory. Once again, I agree.
Building a Kanban board
published March 10, 2011
We have been using Scrum in my current project from the beginning of 2010. Our team is swarming pretty effectively on tasks and we decided that next step would be to try out Kanban as we are currently in “production” mode and see the end of our project closing.
I started this process by reading Kanban book by David J. Anderson which I highly recommend. In his book, David suggest that transition to Kanban should be started small and from the area of team’s “political control”. Board should be designed to fit current process and team should not try to optimize process prematurely. In addition, we knew that in our case input to the Kanban system would be a Scrum backlog. Armed with this information we started to sketch first the version of our board.
Sketching the version one
Layout of your Kanban board will depend on your current situation. There isn’t one right layout and people doing the work will have the best knowledge. We started by sketching our current process and thinking what classes of services we would be providing. Classes of services are basically priorities that will be assigned to kanbans so that critical work can cut in line. In our case, we decided to build 2-tier board, where “larger” cards represent user stories and “smaller” cards represent tasks. Apparently, the best practice (or at least some practice) seems to be that user stories are limited by swimlanes and their tasks are limited by “vertical WIP”. Sounds awful but bear with me.
Get some supplies
After initial board was sketched I headed to bookstore to get some tape and post-its in different colors. I tried to find very narrow black tape, but there was no such thing available so instead I bought some electricity tape and a box cutter.
Building the version one
First things first. kanban systems came from Toyota where 5s (Sorting, straightening, shining, standardizing, sustaining) methodology originated. In our case we decided to do something to our “not so shining” whiteboard.
Because I did not find any narrow tape I used a box cutter to slice tape to more stripes.
This turned out to be a bad choice. Surprisingly, I could not do completely straight slices and almost cut my fingers into half. Next time I will find proper sized tape. Anyhow, our board started to build up. Different colored tape turned out to be a good choice. Below you can see the magical metamorphosis.
And so was first version completed.
So how does this board work?
This Kanban board is designed for a four person team, who has been working with Scrum. Work will be pulled into system from product backlog that is handled by a product owner. The team will then develop features after which they are verified by a product owner or someone from business. After verification, the team is responsible for production deployment. Currently, we favor smaller user stories and layout is designed that in mind.
Click on image below to see larger description how our first version works.
Stay tuned!
This is my first attempt to do a Kanban board and there will surely be something to fix. First thing that we will be checking is our WIP limits. Cannot wait to try how this works in practice…
New Scrum certificates
published February 4, 2011
I added Certified Scrum Product owner and Professional Scrum Master I under my belt. Although a certificate does not guarantee that a person actually knows how to do things in practice, it still provides some information on what that person values and that he/she is pushing himself/herself forward. Most beneficial “gems” that I have discovered while studying have been “you don’t know that you don’t know” type of things. Anyways, PSM I test is something that you should consider, at least take a free open assessment.
Utilizing thinking styles in Scrum development
published January 24, 2011
Should all team members participate in all tasks that the team is doing? Scrum advocates cross-functionality but does that mean that everyone should partake in every task? In short, team culture should encourage for teamwork and everyone should have a possibility to influence decisions but in practice it will be good if some specialization occurs. Why? Read on.
Our ultimate goal is to enable self-organization on a team. A team should work like a start-up company (read “The new new Product Development Game”) that self-organizes around a problem and decides how to solve it. In Thinking Styles book, Robert J. Sternberg presents interesting insights about what kinds of tasks actually motivate people. It turns out that people have preferences for specific types of tasks and teams should utilize this information.
What are thinking styles?
A style is a preferred way of thinking. It is not an ability, but rather how we use the abilities we have. We do not have a style, but rather a profile of styles. People may be practically identical in their abilities and yet have very different styles.
People with different thinking styles will, according to Sternberg, prefer working with different kinds of tasks. Also, this difference gives an advantage for a person whose thinking style suits better with a situation at hand. A developer with more “legislative” style will enjoy design work while a developer with a “judical” style finds analytical work more rewarding.
Thinking style profile is constructed from five categories: Function, form, level, scope, and leaning. These categories form a profile for a person that consists, among other things, of preference for design or executive work, motivation by single or multiple goals, big picture vs. detail orientation, and playing by rules or going beyond rules. For a real description, read the book.
Back to Scrum. I think that in ideal world, everyone should be doing tasks that are best suited for their profile and that they enjoy the most. Of course it does not mean that if nobody likes a task, it will not be made. Also, a team should be cross-functional and members should learn new skills outside their comfort zone. But if entire team is playing to their strengths it will increase work motivation and increase product quality. This is actually what self-organization is all about, people volunteering for tasks.
Nice subject for a retrospective
If a team is aware of others thinking styles it can self-organize more effectively. Therefore, if you don’t know what are the thinking styles in your Scrum team find that out in a retrospective, it will make a nice subject.
Driving a Scrum team at the edge of chaos
published December 12, 2010
Recently I have tried to understand chaos theory and complex adaptive systems and how those relate to Scrum teams. Especially, I am interested in the “edge of chaos” concept and how that applies to my work. There are sources like this and this, claiming that team of people are very creative at the edge of chaos. When I tried to understand what this really means, I had to start from the Agreement and Certainty Matrix.
The Agreement and Certainty Matrix
Also known as the “Stacey matrix”, is a management tool by Ralph Stacey for leaders to get guidance on how to manage people’s work depending on a problem’s complexity and team’s agreement levels.
Close to certainty
Issues or decisions are close to certainty when cause and effect linkages can be determined. This is usually the case when a very similar issue or decision has been made in the past. One can then extrapolate from past experience to predict the outcome of an action with a good degree of certainty.
Far from certainty
At the other end of the certainty continuum are decisions that are far from certainty. These situations are often unique or at least new to the decision makers. The cause and effect linkages are not clear. Extrapolating from past experience is not a good method to predict outcomes in the far from certainty range.
Agreement
The vertical axis measures the level of agreement about an issue or decision within the group, team or organization. As you would expect, the management or leadership function varies depending on the level of agreement surrounding an issue.
In IT world, If we are building a new solution with a technology that is new to developers we are moving from left to right in the matrix. When team does not agree on how technology should be applied, movement is upwards in the matrix. So far this makes sense. If we have challenges on only one area, project tends to be complicated but when both areas are challenging, we are working with a complex problem. Scrum was especially designed to deal with complex problems, where plan-driven approach will not produce best results. In the real world there are no clear boundaries like: “Aha, we just moved into the complex zone, better get us some Scrum”. Even though plan-driven works on simple projects, I think that also they benefit from agile execution.
People are most creative at the edge of chaos
Is this really true? According to excellent book “Group genius“, author claims that a lone genius is a myth and many (if not all) great inventions are a result from collective creativity and cannot be traced back to only one individual. I bet you have seen this personally as well. One person says something, a second one adds a thought, and a third person rephrases the idea. Suddenly a new concept emerges, which is a result from teamwork thus making the team more than a sum of it’s parts. But must all this happen at the edge of chaos and what does that even mean?
At the edge of chaos
Group genius states that collective creativity is the source of great inventions and thus we will need a team to come up with most creative solutions. On the other hand, Stacey matrix states that technology must be challenging and people must disagree if we are working near chaos. This makes sense, as team that always agrees might suffer from groupthink. The scale of Stacey matrix must also be team and situation dependent, as “technologically challenging” depends on the skill level of a team.
Joseph Campbell defines edge of chaos like this:
the edge of chaos is a place where there is enough innovation to keep a living system vibrant, and enough stability to keep it from collapsing into anarchy.
Michael Crighton (In the lost world) like this:
It [the edge of chaos] is a zone of conflict and upheaval, where the old and the new are constantly at war. Finding the balance point must be a delicate matter – if a living system drifts too close, it risks falling over into incoherence and dissolution; but if the system moves too far away from the edge, it becomes rigid, frozen, totalitarian. Both conditions lead to extinction. Too much change is as destructive as too little. Only at the edge of chaos can complex systems flourish. . . And, by implication, extinction is the inevitable result of one or the other strategy – too much change, or too little
If we define a state in which we will not make any progress because “everyone is doing their own thing” as “chaos” then we might have us a setting that can describe “the edge of chaos” in practice. To find out the actual border between chaos and the edge, we must face a situation where we feel that the work is not progressing and stagnation happens. When the team begins to stall because of the disorder, we know that chaos state is reached and some order must be restored to regain momentum. Are you with me?
How to increase chaos in a team
Why would you want to do that? To increase team’s creativity and to energize it to move away from it’s comfort zone.
- Come up with a new point of view and encourage team to discuss why current solution will (or will not) work.
- Facilitate discussions so that also introverts are heard. More insights more chaos.
- Ask team how their solution will work in future and are they taking product vision from all angles into discussion.
- Ask if their solution could be more generalized.
- Focus team on quality and encourage them to avoid one-off solutions.
I do not mean that you should try to guess future requirements and build features that won’t be needed. Purpose is to gain new viewpoints and to twist the problem.
How to decrease chaos in a team
When stagnation happens and chaos is reached, disorder should be decreased so that work can continue. Some ways for a team to decrease disorder are:
- Decrease democracy and select one person to come up with a solution that will work as a starting point.
- Take a small vertical slice and implement a proof of concept.
- Stop discussing and get to work. Once you have something to work with, start discussions again.
- Concentrate on one subsystem in order to reduce complexity on technology axis.
Communication at the edge of chaos
It may take a while for a team to really understand how others perceive a problem and to come up with a potential solution. Without some way to communicate progress team will easily slip into the chaos. I like to visualize things, so I draw. I mean draw like crazy. Class diagrams, domain models, architecture diagrams, story boards, you name it. The purpose of these visualizations is to help team to understand what it has accomplished, give it a shared canvas for discussing about solutions, and to communicate social representations. Biggest value for diagrams is just after drawing and they are not final project documentation as coded solution will most likely be somewhat different from the models.
Some concept models from our current work.
Productivity, creativity, and stress levels
If I have understood the very edge of chaos correctly, it is not very productive state in terms of end user value. Creative yes, productive no. When team is working to gain understanding of a complex issue, it inevitably uses more time to communication and change than when working on straightforward tasks. I feel that actual productivity increase is reached afterwards when we have understood the problem, made a consensus, and pulled out to less complex zone to do actual work. To enter “hyper productive” state, team will have to work like a pendulum, balancing around the edge of chaos. Working near chaos can be quite stressful for a team and it is important to watch how it copes with the stress. It is not a state where I would like to keep team too long at one time, because it will start to wear members down. However, amount of stress at the edge of chaos will likely depend on people’s thinking styles and others are more susceptible to it.
I will have to give more thoughts to this. If you know any good links or have real life experiences to share, I am very interested.
Updated myself with TOGAF certification
published November 24, 2010
It is a quite exiting moment when submitting a Prometric test… Today I passed TOGAF™ Foundation certification test after 3 days of hard studying and that makes me now an enterprise architecture guru, right? Well… not quite. But still, these days have been very good and I have learned lot about enterprise architecture and some best practices to implement it.
I am pretty much Agile and Lean proponent and you might be wondering how they will match up with TOGAF. Basically TOGAF introduces an Architecture Development Method, which is a core process defining how work is to be done. It is very much business focused and tries to find a way for a organization to align business with IT. I somewhat feel that it has same fundamental “problem” as ITIL , namely it manages process with document handovers and sometimes it feels that a document is the purpose for doing something. It surely says that bucks are collected at operations phase, but focus is pretty much with different documentation. OK, both frameworks have roots in big organizations and documentation bureaucracy is more justifiable in those.
TOGAF and ITIL both say that they can and should be customized to fit organizational needs. Then they go describing in detail how work should be done. A process that has to be tailored down is challenging for people as we will usually add some parts “just in case we need it”. This is also a problem with RUP implementations and they just tend to grow too big and non-agile. In this light, a method that describes a process with lots of “potential documentation” can almost accidentally be implemented as “heavy documentation”. It is like selecting movie candies from large selection, you will want to check every row and in the end you just have too much.
TOGAF does not give any guides for software development process and it is easy to implement actual TOGAF work package(s) using Scrum or XP. TOGAF even suggests implementing target architecture in “steps” (transition architectures) that fit nicely with Scrum release plan. However, many benefits of Scrum will be lost if we are just “sprinting though fully preplanned project”. Then again, I am not convinced that every project should be done using Scrum (check out Balancing agility and discipline) and in some cases PMBOK or Kanban approach will suite better. Key is to select correct process and forget about process fanaticism. But either way, people are doing the work, so in the end organization culture must be nurtured to produce top-notch results. Huh, sounds easy :)
All in all, I see very much value in combining TOGAF, Scrum, and ITIL while focusing on shortening lead time by eliminating waste from value chain using Lean tools. Next I will dig into Six Sigma, CMMI and COBIT to build a process behemoth that will solve all problems in the world. No, actually before that I will play few rounds of badminton.
Retro Scrum – coaching with metaphors
published October 24, 2010
“I am wearing multiple hats”, “hats off to the team”, “He was using black hat tactics”, metaphors – we all use them more than we realize. In addition, we have different ways of learning. My learning style is very much visual, so for me it is natural to draw things and learn by grasping big picture first before digging into details. Others learn by listening, but generally metaphors help people understanding new concepts and ideas.
According to wikipedia,
Metaphor is the concept of understanding one thing in terms of another
When coaching, pithy metaphor works like a charm. As people are naturally trying to understand new information by connecting it to previous knowledge, everyday related metaphor can be very effective. In addition, by presenting new information in multiple contexts you will make it easier for a learner to recall that data later. Below is an example of mapping Scrum into everyday cooking metaphor presented in retro theme (I also wanted to practice using Photoshop).
Scrum works like a big happy family (Scrum team) preparing to throw a dinner party (release new feature). Mom (product owner) has written down a menu (product backlog) and requests Dad and daughter (team) to prepare shopping list (sprint backlog), buy groceries and prepare platters (sprint). Family’s eldest son (Scrum master) will keep family’s small children (shields the team) out of kitchen (war room), makes sure that car works, and ensures that dad concentrates on preparing food rather than drinking beer. However, mom will want to check that correct menu is prepared, so she will check platters often (sprint review) and ensures that her party vision will happen. She will probably want to serve food shortly after it is ready, so that quests (users) won’t have to eat cold hamburgers (release often). Dad and daughter must keep kitchen clean (refactor) and try to avoid messy room (technical dept).
There :)
The image is available at Flickr and as A3 size with Attribution-NonCommercial-NoDerivs Creative Commons license.
Communicating product backlog
published October 8, 2010
Many customers that I have had conversation with, feel that one of their major concerns is a possible misunderstanding about product backlog items. Does a team really understand the meaning beneath user stories and is the correct solution built? Are there some good ways to enhance communication between a product owner and a scrum team?
Alistair Cockburn uses term “Richness of communication channel” to describe communication effectiveness between people (see a diagram here). What he claims, is that the least effective communication media is a written document. On the contrary, the most effective communication happens when two people are interacting face-to-face at whiteboard. From my experience, this is true.
Youtube contains nice presentations using motion graphics and scribing that communicate stories pretty smoothly. Walt Disney studios came up with storyboarding during 1930s which is something that is used e.g. in film industry. What I have tried, is to combine elements from all these into a product backlog storyboard in order to increase communication effectiveness.
Lets imagine that our team has to build a new feature to existing software. Product owner has written most of the features as user stories into product backlog. He has also produced some layouts how a UI should look like. These layouts won’t cover the whole solution and only work as a starting point. Problem now is that you have a product backlog which is very “cold” in terms of communication effectiveness and you will somehow have to increase richness when communicating features to the team. so, to be most effective we should meet at a whiteboard, right? Yes, but it is better to prepare stuff before whole team arrives.
What I have done, is drawn multiple storyboards like one below beforehand and used those as a “whiteboard”.
This is close to a user interface mock-up, but it tries to communicate the story without all detail in user interface. Storyboard gives us a shared visual representation and a story flow that can then be enhanced with people present. Storyboards should be hand drawn and are actually pretty fast to do. They can be hanged as a posters on a office wall, or discarded and redrawn in case they are incorrect. Storyboarding is quite effective method in cases where you yet have no real mock-up, and try to get people on same page.
Older Posts »Subscribe to RSS feed
The Tag Cloud
Agile Business Coaching Coding horror Conference Customer Design of Experiments Future Group dynamics ITIL It should not be that hard Java EE Kanban Leadership Lean Liferay Methodologies Natural UI Performance tuning Process Productivity Quality Retrospective RIA Scrum Six Sigma Social psychology Software Software architecture Testing This is great TOGAF
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Samuli's Links
The Blog Archive
February 2012 (1)
January 2012 (1)
November 2011 (1)
June 2011 (2)
May 2011 (1)
April 2011 (2)
March 2011 (2)
February 2011 (1)
January 2011 (1)
December 2010 (1)
November 2010 (1)
October 2010 (3)
September 2010 (3)
August 2010 (5)
July 2010 (2)
June 2010 (3)
May 2010 (4)
April 2010 (2)
March 2010 (6)
February 2010 (7)
January 2010 (3)
December 2009 (7)
November 2009 (6)
