I first got know Chris when we collaborated to start the very first Seattle Scrum Users Group in 2007 and I’ve been following him ever since. You should check out his blog at http://www.gettingagile.com/.

Have you ever heard or said any of these phrases?

• We are going to implement the Scrum methodology.
• We’re doing a modified Scrum.
• Our developers are using a Scrum process.

These may seem like innocuous statements but they are indicators of potential misinterpretation of how Scrum is best utilized. Scrum is not a full development process (although almost anything that has steps could be considered a ‘process’) and it is not a methodology. It does not tell you how to implement the software. It is a simple-looking framework that will help a group developing products figure out what is not working well so they can fix it. Here is the Scrum framework diagram:

The Scrum Framework

At first, people and teams implementing Scrum focus on the process without understanding why and how to do each piece effectively. We believe that we will be “doing Scrum”, and will gain all of its benefits, by just:

• Keeping a list of work (the Product Backlog)
• Assigning it to the team during a Sprint Planning meeting
• Doing that work over the course of the Sprint

This focus on going through the steps can be dangerous and frustrating for individuals, teams, and managers. Scrum is NOT A SILVER BULLET! No process, practices, or techniques are. Instead of focusing on the process, practices, and techniques of Scrum, I suggest individuals, teams, and management focus on the learning that can be produced by a team doing Scrum and act on that learning.

Scrum is an Empirical Process Control. The idea is that you plan and then do something, inspect what you did, and then adapt your behavior to improve on what you did. It is a learning framework for product development teams. This learning cycle is referred to as “inspect and adapt”. All 3 Scrum roles are involved in the learning: the Product Owner, ScrumMaster, and Developers (when I say developers I mean anybody needed to build the product, not just coders). In Scrum, there are 3 specific “inspect and adapt” cycles:

• The Daily Scrum meeting allows the team to focus on their commitment for the current Sprint and whether they are still on track to deliver on that commitment. If they are not able to meet the commitment then they are asked to adjust the Sprint, thereby adapting to the situation.
• The Sprint Review meeting allows customers to view a potentially shippable product increment created by the Team and provide feedback that adjusts the Product Backlog contents and priorities. We are inspecting the product and adapting to a new understanding of the product.
• The Sprint Retrospective enables the Team to improve the process they use to delivery software each Sprint. The Team is expected to inspect their process honestly and thoroughly to figure out how they can adjust for improved delivery capability in the following Sprint.

If you read my blog often, you might recognize this from a previous post called “Kaizen Mindset” that has good information on how to use learnings and manage the impediments around those learnings.

Scrum is more of a tool than a methodology. It will make visible what is not going as well as it could be. It is then up to people in the team and organization to make changes to improve it. With each incremental improvement the product development team will move that much more effectively on its work. Rather than focusing on getting perfect at the steps in the Scrum framework, find out what can be improved in your delivery process and adapt it accordingly. If a part of the Scrum framework is difficult to do or seems like a waste then instead of eliminating that part, find out why it is difficult or wasteful in its adoption. There is usually a hidden impediment behind these difficulties and perceptions that if eliminated will allow the product development team to be more effective.

Scrum is not a destination. It is rather a tool that a product development team uses to continually inspect and adapt their way to more effective delivery. The destination should be your business and development team effectiveness goals. How can we deliver more product? How can we reduce time from inception of project to release? How can we release more often at a lower cost for release stabilization of the product? How can we reduce the risk in our project delivery and portfolio? The destination should be substantial and worthwhile. Scrum is just the vehicle to help get you there.

I am a software development consultant and coach with over thirty years of experience creating software ranging from small embedded systems to corporate enterprise systems. With a strong interest in lifelong learning, I have pursued more effective ways of creating software at the technical, interpersonal and organizational levels. My specialty is helping teams become more effective while helping them accomplish their current project. I practice consulting, coaching, mentoring, teaching and training.

You should check out more great articles by George on his blog at http://blog.gdinwiddie.com/.

Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with

• A list of features to be built
• A release plan or timeline for those features
• Setting up development infrastructure such as version control or continuous integration servers
• Studying or practicing skills in new technologies they expect to use
• … and other management, infrastructure, and technical endeavors.

They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project. The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.

And we’ll have burned an iteration without producing any working software that tests our decisions.

My advice is to borrow an idea from Lean and look at the situation from the output point of view. Ask yourself, “what would it take to start delivering?”

The initial backlog really only needs to be one item in order to start delivering. If you’ve got too many unknowns, then just start with one item. Get the business stakeholders, the programmers, the testers, and anyone else who needs to be in on the discussion (User Experience? Ops?) to talks about it. (I call this a meeting of the Three Amigos.) What is the one obvious thing that needs to be done? (Hint: it’s not “login.” Start with the main purpose of the system.) I can’t imagine a situation where a project is started without any ideas at all.

Take that one thing, and slice it into thinner slices. Decide on the examples that represent acceptance of those slices. Some of the slices will have questions that can’t be answered. Put those aside for the moment. Choose the most central slice that travels through the entire concept from end to end, or as close to that as possible. Estimate that as one team-iteration. (Estimates don’t have to be “right.” They’re just estimates.) Start building it.

Learn the necessary skills in the technology while accomplishing real work. Learn the parts that aid building the system, rather than developing the system according to some framework. When you don’t know how to accomplish something, or you think multiple approaches might work, do minimalistic spikes to give the information needed to make a decision.

Along the way, start slowly building your development infrastructure. Set up a local code repository. You can always migrate the code to an “official corporate” repository later. Right now, there’s not much code. Set up a simple build-and-test script so that everyone builds in the same fashion. You can always add other build targets later. If you’ve got time, you can set up a Continuous Integration server. Otherwise, just do it manually. Checkout & build into a clean workspace. Do what’s needed to run the code so that you can show it working.

If you can’t accomplish this slice in one iteration, it’s probably not thin enough. Or, maybe you haven’t yet solved an essential technical problem. Or the goal isn’t yet clear enough. Figure out what impediment is most in your way, address that, and try again.

More likely, you’ll get this slice done in less than a iteration length. If you get this slice done before the end of the iteration, then pull in another slice. Estimate this as “the rest of the iteration.” Repeat as needed. As long as you’ve gotten one slice done, you’ve got a potentially deliverable product increment.

Yes, there will still be development infrastructure to be developed. There’s no particular rush to get that done. Just keep improving it, so that it helps you get more done. Yes, there will still be technical skills to be developed. That should always be the case. Just keep experimenting and pushing your limits.

Yes, there will still be features to be added to the backlog, refined, prioritized, split into stories, and prioritized again. This should continue throughout the project. It’s part of the “steering” process. Yes, there will still be a need for projections to estimate when functionality can be released, or how much functionality can be released by a certain date. When you think you’ve got enough information about what needs to be done, then consider the initial release plan. By then you’ll also have accumulated a little information about how fast things get done.

There will still be a lot of holes in your knowledge of what needs to be done and how fast things get done. Don’t trust your initial release plan to be “right.” It’s just a stick in the sand to help you judge how things are going. Keep planning, and move the stick as needed. And as time passes, you’ll have a better and better indication of how fast the system gets developed. Even when you think the Release Plan is complete, it needs to be continually reviewed and adjusted. Since it’s never done until the release, there’s no particular hurry for a certain level of completeness.

This sort of beginning is very like the Hudson Bay Start that Johanna Rothman describes in her book, Manage It (pp. 52-53).

The Hudson Bay Start approach was originated by the Hudson Bay Company in the 1600-1700s in northeastern Canada. The Hudson Bay Company outfitted fur traders. To make sure the traders hadn’t forgotten anything they needed, they left Hudson Bay and camped just a few miles away. By making camp just a few miles away, the traders ensured they hadn’t forgotten any tools or supplies–before they abandoned civilization. With just a short start to their journey, they had a better idea about their ability to endure the winter.

There’s really no reason (other than “that’s not the way we do things around here”) that this can’t work for the start of any team/project. It’s a great way of learning the right stuff for the current situation while also making a bit of progress. I use this technique in my Agile in Six Months transition plan.

I first got know Chris when we collaborated to start the very first Seattle Scrum Users Group in 2007 and I’ve been following him ever since. You should check out his blog at http://www.gettingagile.com/.

At the last Scrum Trainer’s Retreat in Boston, MA, Lowell Lindstrom presented a 30-minute exercise on Affinity Estimating. Kane Mar has written a short blog entry on this technique for sizing a large Product Backlog here. I would like to add some context for the exercise and a step-by-step that I have found useful since using this and other similar techniques. Although I do not suggest having Product Backlogs of enormous size, this exercise has been successfully run in my presence with over 300 items in 2 hours. I recommend that this exercise is used when you have more than 20 items to size. When less than 20 I find that Planning Poker or a more sequential approach may be more appropriate.

Prerequisites

In preparation for this exercise, the Product Owner must have a list items in their Product Backlog which are to be sized by the Team(s). I suggest that the Product Backlog items are each put onto their own index card, post-it note, or better yet perforated and printable Avery index cards. Also consider holding the exercise in a room with a large wall that you can stick Product Backlog items onto. If you are using paper print outs of your Product Backlog items then you may need to bring blue painter’s tape or some other sticky substance to adhere them to the wall. You may also wish to bring stickers, black sharpies, extra index cards or post-it notes, and multi-colored markers.

Step 1: Silent Relative Sizing

As shown above, place an X-Large post-it note or index card on the far left side of the wall with “Smaller” written on it. On the far right side of the wall place another which says “Larger”. Let the Teams know some simple guidelines which may help the relative sizing exercise, such as:

• Team members will be asked to come up to the wall with a subset of the Product Backlog items provided by the Product Owner
• Team members will be expected to size each item relative to other items on the wall considering the effort involved in implementing it based on our Definition of Done
• This is a silent part of the exercise so please refrain from speaking to others except for basic comments like “move out of my way”
• The Product Owner and any helpful stakeholders/supporters will be present towards the back of this room to provide clarity when needed, so please ask them for help when not sure about an item
• Team members may use a place in the room to capture questionable Product Backlog items such as items which are too ambiguous to size even after discussion with the Product Owner
• Think of the wall as a spectrum of size from Smaller to Larger; items stacked vertically on the wall are about the same relative size in effort

I have facilitated this exercise with teams of 5 to 45. When working with a larger number of team members it is important to use good facilitation techniques such as phased work in smaller groups at the wall. Please find resources on the Internet and with your HR department on facilitation for more specific tips when working with the large groups.

Run the silent relative sizing until all Product Backlog items are up on the wall or in the space reserved for questionable items. This can take anywhere from 5-20 minutes depending on the number of items and team members.

Step 2: Wikipedia-like Editing of Wall

Now it is time for Team(s) to edit the relative sizing on the wall. Ask team members to read the Product Backlog items on the wall and move them around as needed in either direction, smaller or larger. Explain to the Team(s) that we should be considerate of other team member’s estimates and therefore bring others into the conversation when appropriate before making extreme moves.

During this part of the exercise you may see some design discussions going on, thoughts about Product Backlog items which are missing, and increased clarifications needed from the Product Owner. Allow this to continue until the Team(s) begin to settle down and there seems to be little change happening on the wall. This may take 20-60 minutes to complete.

Step 3: Place Items into Relative Sizing Buckets

Once all of the Product Backlog items have been placed onto the wall and edited by the Team(s) our job is to get them placed in size buckets. Depending upon the nomenclature that the Team(s) decided to use place the sizes along the spectrum at the top of the wall between smaller and larger. For instance, if you are using Fibonacci sequence for your story point nomenclature, place the 5 further away from 3 than 3 is from 2 on the spectrum. If you are using T-Shirt sizing then may decide to use a doubling or just increasing spacing as sizes get larger. It should look something like the picture below after you put up the sizes:

Ask the Team(s) to decide which size the Product Backlog items fit under based upon the relative size location on the wall. Explain that we need to make the sizing clear so leave space between buckets of sized items. After this has completed the wall may look something like the following:

Step 4: Product Owner “Challenge”

Once the Team(s) have sized the Product Backlog items on the wall the Product Owner is probably anxious to discuss some of the sizes. I usually give the Product Owner and any of their supporters a colorful pen or stickers to mark items they would like to discuss with the Team(s). This is also a good time for the Team(s) to take a 15-minute break to recover from the estimating work they have done so far.

It is important to tell the Product Owner and their supporters that the word “challenge” is not to disrespect the estimates of the Team(s). Be careful how you approach the challenge and make sure that you are communicating what about the item’s size was not inline with your thoughts of it’s size. I may even prepare them with some Planning Poker Tells that may be noticed by the Team(s) while they are challenging items.

When the Team(s) get back from break have them get comfortable and allow the Product Owner and supporters to ask about items they have marked on the wall. The Team(s) discuss their reasons for the size associated with each item. You can take multiple approaches in terms of changing sizes based on the Team(s) input:

1. When team members decide that an item should be resized put it onto a separate wall for resizing after challenge has completed.
2. Have team members decide on the spot with the Product Owner what the new size is.

Although the first of these choices seems best I have found the second to be sufficient in most circumstances. This step is completed once all of the challenged items have been discussed. This may take anywhere from 20-60 minutes.

Step 5: Get it into an Electronic Tool

Of course, we should make sure that the information is not lost once the estimating has been completed. Make sure to get the estimates into your tool of choice for Product Backlog management ASAP. I usually write the estimated size on each Product Backlog item before taking them off the wall and transferring into the tool.

What Else?

I found a few nuggets in running this exercise which I believe to be helpful:

• The Affinity Estimating exercise is best conducted on Product Backlogs larger than 20 items. It is best when you have at least 40 items which allows for groupings to easily become apparent.
• Some Product Backlog items may not be understood enough to estimate at all. Place these on a space separate from the estimating wall so the Product Owner can take them away and clarify them.
• Leaving the sizing nomenclature off the wall until the full sizing steps 1 & 2 are completed helps Team(s) use relative sizing.
• Ask the Team(s) to decide on a common sizing nomenclature such as T-shirt (XS, S, M, L, XL), Fibonacci (1, 2, 3, 5, 8, 13), or 2n (2, 4, 8, 16, 32) before starting step 3 if they haven’t already decided.
• Spacing of sizes relative to the gap between the numbers across the wall can help team members put items into size buckets.
• Be careful and work with the Product Owner and their supporters to understand how the “challenge” of sizes can be effective and still respect the Team(s) estimates.
• ScrumMaster must be ready to do heavy facilitation with a single team. If you are conducting the exercise with multiple teams it is imperative that each step is setup well. I have facilitated this exercise with 3, 4, and 5 product teams in the room. It works well in this situation with healthy facilitation.
• This exercise does not remove the need to conduct more in depth estimating sessions such as with Planning Poker as the Product Backlog evolves.

Try it out and let me know in the comments if there are any additions or modifications you would like to make. I believe the Affinity Estimating exercise will be helpful to those dealing with large Product Backlogs in getting initial estimates. Thank you Lowell and Kane for exposing this exercise to us.

Beware! There will be a sidle. Watch for it, be prepared for it. Don’t avoid it.

What is the sidle? The sidle is simply, one person who hangs back … the conversation after the conversation; the hallway conversation; the kitchen cup-o-tea conversation.

This is vitally important to realise, to prepare for as a leader. The sidle could indicate many things;

• Perhaps the person is uncomfortable sharing their thought / question with everyone.
• Perhaps there’s a hidden agenda.
• There’s a question that wasn’t asked that is burning.
• There’s a reliance on you as a leader to communicate – and you haven’t.

Whilst agreement seems to be reached in the meeting – it’s the conversation after the conversation that can make the difference. A wiser person than I mentioned that there would always be questions. Wait. If there’s none, wait some more. There will be questions in the room.

The sidle used to irritate me. I used to feel so frustrated, because in me there would be a sense of urgency. I felt like I had ‘dealt with the issue’ in the room – and it was now time to move on.

I’ve learned since – that this feeling is my feeling. If there is a sidle (and there usually is) then it is a good thing. I can help this person. I can encourage the person, help them with the question.

Given the sidle is time expensive – and we are in a world that tends to rush from meeting to meeting … How do you deal with the sidle?

… helps people to build successful, business critical IT solutions. That is why highly productive teams, state of the art technical solutions, and products with high return on investment are things that really make me tick.

I have spent the last 12 years working in IT projects. During these years I have occupied roles such as Scrum Master, project manager, auditor, architect, and developer. I believe that success stacks up over time and prosperous solutions are built by succeeding every day. My consulting services help both struggling and already successful teams to build IT solutions for today’s real business needs.

You should check out his website at http://www.samuliheljo.com/

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.

Regular readers may notice that I’ve done occasional guest posts. These have introduced some variety to this blog both in terms of topic and style. Although I try very hard to write regularly, I find that a blog written by a single person can become very monochromatic, for lack of a better word. So, I find the guest posts refreshing.

This year I intend to extend the guest posts. I recently reached out to bloggers whose work I enjoy, and asked them if I could re-publish their work as guest posts. They agreed, and so over the next few months I’ll be sharing some great articles by some of the most experienced people in the Agile community.

[Technical Note: I'll be using the cross-domain rel="canonical" link element to prevent problems with Google and duplicate content. As I understand it, this allows me to point to the original text of the article so that the authors get full link karma from Google. Here's how Google explains the use of rel="canonical".]

The very first post will appear in a few days and will be an article by Samuli Heljo titled “Reflections on Kanban vs. Scrum development.” Shortly after that I’ll have guest posts by Chris Sterling with “Affinity Estimating“, George Dinwiddie with “What is an Agile Coach”, and Jonathan Coleman.

Do you write a blog on Agile software development? Do you have content that would be of interest to the Agile community? Would you like to write a guest post?