So you can't do Scrum

 If you find yourself in a situation where you’d like to adopt or transform from a waterfall to an agile method but there is a big road block in your way, what should you do?  Perhaps an executive has issued a proclamation against agile, contractual issues prevent it, or key stakeholders just do not want to make that change. The question is presuming that you are attracted to Agile but you just can’t get there, so now what?

When I was recently faced with this same question my initial response was well that’s too bad, just keep doing what you have been.  Hybrid agile things are often not a good idea. They just create confusion and sometimes extra non value producing work.   The risk is people cherry pick practices from different methods and use the “introduction” of agile as an excuse not to exercise discipline in how they operate.  See related post on Shu ha ri http://agileadventure.blogspot.com/2013/04/shu-ha-ri-and-self-organizing-teams.html#links The second risk is that a halfhearted adoption of agile has a great possibility of “poisoning the well” for a latter successful adoption.  There is already some significant factor holding back the adoption of agile; those naysayers will point to the weaknesses in the half adoption as reasons why it is not a good idea to begin with. Then it makes a subsequent decision for this team to adopt an agile method like scrum even more problematic.

So I say if you can’t go Agile then don’t go half way.  But this response is probably not going to be satisfying to the person asking the question “now what?”  They may even think deeper about this and say “you mean to say I can’t iteratively and incrementally approach my agile transformation in an agile fashion?”

So here is my advice.  Don’t claim you are practicing Scrum and don’t try to practice Scrum, the leading agile methodology.  What you can do is embrace agile values and continue with your current method.  The Agile manifesto is as much a declaration of values more than anything else.  The “Twelve principals of Agile Software” is another good source of guidance http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/    What you can do look for alignment that people are doing what they said they would do, are they learning, is working code being produced.  For example:

·         If you already have a practice of doing weekly status reports you can pretend that you are operating in one week sprints. Most status reports contain a section on what we did last week and what we intend to do next week.  Follow up with folks.  Did they really do what they said they would do last week, have a discussion over the reasons why not and acknowledge the success when it happens.

·          Ask if they’d like to have a brief discussion before they write up their goals for the next weekly status report.  See if you can identify impediments that they will need help with.

·         Ask “when can I see a demo?” Assert that you’d rather see something early and untested if necessary.

·         Walk around and engage people in face to face conversation.  You’ll be surprised at what you learn.

·         You can hold a retrospective without saying “retrospective” ask “what did we learn from doing that?” Create space for the ensuing discussion.

·         For every document produced by your current non agile development process (especially those in excess of 10 pages) ask the author(s) “who is the audience for that document?” I’ve been amazed at the number of people who create documents because the process says they need to but they are unaware of who is supposed to consume that document.

·         When discussing features ask “how many times does that happen?” or “What would happen if the system didn't support that?”

Shu Ha Ri and self organizing teams

Preface. I've been away from this blog for a while as I've been on projects with a high degree of security and afraid of disclosing something inadvertently. But since this article references my son Jason and I don't believe I am disclosing any secrets it is here for all to see.

 I recently ended an engagement with a customer as an Agile Coach. I learned a lot from the experience and I'm gratified by many of the comments I've received from those I worked with on the project. None the less as I've had a chance to reflect on this engagement it brings to mind that we should recognize that there are multiple strategies to follow regarding the process some refer to as Agile Transformation. In many cases managers observe a sea change and decide that they also want an Agile organization. Or they read a report from a leading industry analyst that says in so many years 80% of all projects will be Agile. How one goes about that Agile transformation is critical for determining the outcome of the transformation effort.

Culture and organizational norms are an important factor in the strategy to engage in agile transformation. Years ago a colleague said to me "just tell them what you want them to do and stop asking so many questions." I was initially shocked by such a comment. But now I realize that I was not reading and adjusting to the situation I was in. I was continuing an engagement style that I had fallen in to the habit of that was more appropriate for a team that was at Ha or Ri. (if you are not familiar with the Shu Ha Ri stages of mastery I urge you to check out work by Alister Cockburn at http://alistair.cockburn.us/Shu+Ha+Ri.) These are Japanese words and roughly translated they mean first learn, then detach, and finally transcend.

 I think this dynamic is also at play in certain situations when I work with someone and and they ask for help with a tool or a program. I am always inclined to want to give people a fishing pole thinking it is more valuable than a fish. (Give a man a fishing pole you will feed him of a life time, given him fish and you feed him for a day) But what I miss is that they just want and need to experience an initial success. They don't need all the theory and such. My son will even tell me sometimes "Dad, I just want a fish". This is code for stop explaining and just tell me what I need to be successful one time. I need to learn patience so that their initial success will generate hunger for the fishing pole.Then I can teach.

 The Shu Ha Ri wisdom says for a beginner, some one at Shu ,they should rigorously follow the rituals and ceremonies described by the practice until it has become ingrained and part of their "muscle memory". The thinking is that until they have lived it and personally witnessed the benefits and achieved a deep understanding they are not yet in a position to tailor or depart from the tradition. Unfortunately this notion runs smack into a conflict with the notion of a self organizing team.

People begin their Agile transformation with a short course. They hear about self organizing teams and then after they start practicing scrum they say this business of standing up for the 15 min daily scrum meeting is silly. Lets all sit in the comfy chairs at the nice conference table and have a 30 to 60 minute meeting. We are are going to self organize this meeting to something we are more comfortable with. This begs the question - is the right to self organize something a team earns or is available from the start?

 My personal journey to "be Agile" came through a variety of initiatives that were more evolutionary in their nature. Small incremental inspect and adapt cycles towards becoming more Agile. Until my most recent engagement I assumed that was the appropriate path for every one else.

Now having more experience with highly structured and command and control/para military type organizations more common in government organizations I can see the wisdom of Shu Ha Ri. Assuming there is support from the leadership in the organization an organization with a strong command and control culture is probably better off with more radical and abrupt adoption of Agile practices along the lines of Shu Ha Ri. They don't get to use the self organizing principal as a license to bend and adjust practices till they have delivered 100 units of value or some other metric of real progress and accomplishment. They need to get past Shu before they can self organize.

 Consider an organization that has had some success and wants to begin a transformation to Agile.They had already achieved a certain level of maturity and may already have a software process improvement effort underway of many years a gradual adoption of Agile may make sense. They get to credit for their past success and more rapidly pass through Shu on to Ha and eventually Ri. Because they have a legacy of producing working software I'd say they have more latitude to adapt and self organize.

So I've learned that it is critically important to read the setting and adjust gears, For a new team, especially one grounded in command and control, rigorous application of agile practices and ceremony is important for success. Teams that have a history of producing working software have earned the right to adjust and transcend the traditional practices.

A Virtual Daily Scrum

This note has a slightly more formal tone than my last few posts. I've decided to start capturing or creating some process nugets that I can use in my next position where ever that may be. Hence I'm posting them here for anyone to comment on.

Abstract:
One of the key processes in an Agile Scrum development is the daily stand up or Scrum meeting. Yet there are many teams who seek to be Agile but are part of distributed or virtual teams. This article describes a mitigation for the the lack of collocation either due to permanent distribution as in geographically distributed teams or “plan B” meetings on “snow days”. This virtual daily scrum process cannot replace the benefits for a real scrum meeting with rich non verbal communication but it can be a very effective process in a distributed or “Scrum But” environment.


“Necessity is the mother of invention. “ After having had the experience of leading Agile teams and doing some consulting on Agile adoption I found myself in a new situation with a widely distributed team that was enthusiastic about moving to an Agile development process but couldn’t change the fact that they were distributed across 3 continents. I was well aware that a truly effective Agile team is collocated yet we had some people working from home and others 10.5 time zones away. What could we do? My sense was that we were not alone and distributed teams are very popular and not just unique to my organization.
Thinking about this I noted that my children were utilizing various types of social media mechanisms to share information about all sorts of things that teens and twenty something’s talk about. (Twitter, FaceBook, text messages, etc) These kids have very little in the way of financial resources yet they have a better communication infrastructure than I do in my for profit organization with a million dollar project budget! The conclusion I came to is that we could have a virtual daily scrum as one of the corner stone communication processes in our distributed team that wanted to be Agile. We couldn’t do conference calls on a daily basis because we were already doing weekly team meetings. The imposition and personal stress that live daily teleconferences would involve on a daily basis would be too much for many of the team members. That left us with the written word as the communication medium.
We ran for a while with a specially customized team discussion SharePoint web part but later settled on using Yammer after one of the team members discovered and suggested using this for the virtual daily scrum meeting. See http://Yammer.com . There are also a growing set of tools that support collaboration among Agile team members. I suspect if they haven’t already, some will support this process. My team was financially constrained and we were lucky in that we could deploy Yammer without getting approval for spending money.
Yammer is a web site which resembles Twitter but is designed for business. A key difference from Twitter is that one can control the scope of communication with a Yammer group. With Yammer communication is implicitly limited to individuals with the same email domain name. Hence with Yammer one can only communicate with co workers. However with a Yammer group, a Scrum Master or some team member can invite and further control who can participate and view messages that are posted to the group. The Yammer group then consists of everyone who would participate in a typical daily Scrum team meeting. If your organization has even more stringent administration or security requirements there are for fee models of Yammer usage.
The primary activity for a team member when participating in a Virtual daily Scrum is to post a simple short message (under 140 characters) that answers the daily question “what are you working on and what if anything, is blocking you”. They should also “listen to” or review the most recent postings of other team members in the same group.
Yammer supports two different communication models. One is “following” individuals; the other is “Group” communication. Yammer allows people to “follow” other people in the same company to view and reply to messages posted just as is done in public with Twitter but that communication is outside and beyond this process description. Whoever facilitates the introduction of Yammer and virtual daily scrums to the team should discourage but not forbid people from “following” other people. For people where this is a new communication process “following” people will just make initial adoption more confusing. On the other hand if they understand and are enthusiastic about following people let them go ahead. Just explain that “following” is beyond the virtual daily scrum meeting process that you are trying to facilitate. It is important that all understand the two different types of communication with different goals otherwise people will view it as one Yammer blob.
One of the members serves as a moderator. One of the members of the group leads by making their own postings and monitoring what is going on just as a Scrum Master would do in a normal live meeting. Yammer has the role of group administrator. This person invites people to participate in the group and accepts of rejects requests for membership in the group. Ideally a group will be self organizing and establish norms that best serve the group. The following norms have arisen in successful groups in past projects.
• Every project team member creates one post per day. If you are familiar with the “pigs and chickens” metaphor, each “pig” should post one message every work day. Chickens (people who monitor the project) may be part of the Yammer group but should just read messages and follow up off line.
• The group moderator limits membership in the group to project team members. It can inhibit communication if too many people are present in the group. An especially tricky situation to manage is if the CIO, CTO or other executive asks to be part of this group. The Scrum master should personally discuss the pros and cons with the executive. Consider asking if this was a real meeting would they attend and indicate that you are attempting to emulate a real meeting.
• 80% or more of the content is project related. As in any meeting, an occasional comment about a sports team or new baby keeps things interesting but if discussion deviates too far from project work someone should bring things back to focus.
• Minimal use of the “reply” to group message. Hopefully the messages posted in the Yammer group will in some cases lead to conversations, phone calls, email, instant messages or other follow up communication. This is similar to the norm in a real scrum meeting of follow up discussion offline only with affected parties.
• Do not use Yammer as a platform to challenge or disagree with someone. The communication bandwidth is too low. Pick up the phone or arrange a real meeting.
Controlling the scope of communication with a Yammer group is important because it helps provide the same dynamic as limiting the standup meeting to 15 minutes. If one is expected to post a message and view the messages of several dozen people, this process is likely to break down. The fuzzy boundary and time commitment to view the postings of a large number of people slows adoption. With this process supported by Yammer we don’t forbid people from “following” others as they may do with Twitter but “following” people is a completely extraneous use of Yammer for a virtual daily scrum.
This is different and one can’t achieve the same benefits as a real daily scrum meeting that a collocated team can have but my distributed team adopted this process without much promotion. People seem to realize these benefits.
• Greater sense of community or team that couldn’t be achieved otherwise.
• Use of textual communication is sometimes easier for people who don’t all have English as their primary language.
• Support for a picture of the person is a nice touch and seems to foster more communication by making team members more aware of each other as people. Yammer helps this to happen in a really low overhead fashion. I’ve never prompted people to post their picture, 90% naturally just do it.
• Greater awareness of what each other is doing promotes more sharing and discourages working in silos and the subsequent integration issues. Working in silos is a greater risk when teams are distributed.
• Writing down each day what you hope to accomplish with it visible for all encourages faster learning. When you create a post each day using Yammer the words you wrote yesterday are right in front of you. The stage is set to encourage the personal reflection that promotes growth and learning. Hopefully, thoughts arise such as the following without anyone’s intervention- “Yesterday I said I’d complete unit testing of X, now it seems I still need another day. What did I miss that caused me to miss my estimate? Can I really get it done today?” In this respect it might actually encourage more leaning and accountability than a verbal comment in a real Scrum meeting where the words one said yesterday are not quite as present the next day.

A real scrum meeting is optimal and it is not suggested to use this when there is a choice. There is a lot that gets communicated by gestures, facial expressions and tone of voice that one can’t get with virtual daily scrum. Yet there is also a benefit to having the persistent written word to foster reflection on reality that encourages learning. Having the virtual daily scrum in your process tool box is a good idea someday you just may need to use it.

what about my old meterics

A few weeks ago I spoke at the PMI chapter meeting http://www.pmi-swohio-chapter.org/present.shtml on some experiences from "my agile journey". The timing of this worked out really well being unemployed and all. One would think I'd have more time to blog but finding a new opportunity is a very challenging, time consuming and interesting project. In any case I appreciated the professional stimulation and engagement that was not related to finding employment. I especially appreciated the questions.
There was one question that caused me to pause, unfortunately the woman who asked the question came up to me latter and apologized for putting me on the spot. Reality was it was those kind of questions that motivate me to give such talks and I thank her. If I can find her contact info I will forward this on. I probably didn't give the smoothest answer; so now sometime latter let me try again.

As I recall the question went something like this- "We've been trying to adopt an agile approach but we have a problem with one of our established metrics that people track. That metric is the days a bug report is open. With sprints sometimes we don't get to fixing a bug for many weeks and this is being raised as a problem with our agile adoption."

My quick answer is you should be considering resolution of the bug as part of sprint planning every 2-4 weeks. If the product owner and team decided that other work was more important than that's where the priority is. I recommend that you make sure all then necessary stakeholders are participating in sprint planning.

The longer story I didn't have on the tip of my tongue or the time to deliver goes like this. First when a team begins the agile journey they tend to carry over some habits or patterns from the waterfall world and just look at agile as a series of small waterfalls. They look at the work in a sprint as just the development tasks and don't establish any quality goals or metrics that help define what it means to be done with work in the sprint. If they are sprinting along and building up a bunch of bugs that aren't getting fixed then the person raising the yellow flag about the increase in duration for open bugs is raising a valid alarm. In that case they have sort of a cafeteria style agile where some practices are adopted and others are not. This is a common problem and one that the team should recognize and deal with. A healthy team adopting agile should not be building up an increasing stack of open bugs. Somewhere there should be the idea of "potentially shippable code" every sprint.
Second in the agile world one needs to look more carefully at what is means for something to be a bug. Let me describe two examples. In case A when someone clicks the OK button after a certain set of steps the system responds with "Access violation" or "Invalid object reference" This is clearly a unacceptable response and the result of some type of implementation error. This is a classic bug. However consider case B when someone clicks the OK button the system responds with a message indicating "no x selected". The user looks at the screen and there is only one choice for things of type x. They may think something like "why do I have to select black as a color when black is the only choice available." The program should be smart enough to realize that and make the selection automatically. This may also be consider a bug.
In case B the problem is most likely due to a flaw in the requirements or a use story. It is sometimes referred to as an emergent requirement. It was a difficult requirement to specify until the customer had some experience with the system and could actually see the problem. The bug represented in case B may be something that every recognizes is a bug but the severity or consequences are not as great as case A. The team and product owner may prioritize other work to be done before working on the bug like the one in case B. If that's the business decision then that's how it should go. Maybe the frequence of the user encountering this case is very low. The bug in case B may stay open for several sprints or even across multiple releases. The key point here is an explict decision (or multiple decisions) was made not to address case B in favor of something else that had higher business value.
Assuming these tradeoffs and decisions are being made, the the question of the standing of the traditional metric bug open duration is called into question. One would have to consider if the metrics truely supported governance of the development process or if they are a carry over from a different process? Hence it is hard question to answer with out context.

Agile as an "on ramp" to project management maturity

Three ideas came together a few weeks ago that provide the topic for this posting.

First while browsing the agile virtual community I encountered a reference to a youTube video with the headline "Learn the Agile software development methodology in less than 10 minutes. "
http://www.youtube.com/watch?v=Q5k7a9YEoUI

Second I was reading the abstracts of talks by some thought leaders that offer to clear up the multiple misconceptions about Agile.

Third, I was thinking deeply about adoption of Agile in my current situation.

I was initially impressed by the 10 minute video, it gives a nice concise definition of some common vocabulary and roles used in an Agile project. Yet, I fear it also contributes to the misunderstanding that experienced agile practitioners talk to others about. It may also lead executives with P/L responsibility to look at Agile methods with less respect and confidence.

I believe that there are also others who started their "agile journey" more recently or at a different place who tend to view Agile methods as light weight or more suited for the free spirited. They may be attracted to Agile methods as the least invasive of a variety of alternatives.

The more seasoned players my look at all of this with some degree of skepticism. They think how can something that simple support the claims being made.

In light of all this I have to offer my brief point of view. The process description is simple. Yet the organizational climate in which that process can thrive is no simple matter to achieve. Getting people to be accountable is hard. Getting out of the "it's not my job" mentality can be a challenge way beyond what one can learn in 10 minutes. How to create the foundational alignment and climate is what I'm learning and hope to continue to learn.

To do this I view presentations on motivation by people such as Dan Pink http://www.ted.com/talks/dan_pink_on_motivation.html and I listen deeply to team members who challenge me with statements like "why isn't it enough that I come to work every day and do good work".

The "agile manifesto" or the "declaration of interdependence" http://pmdoi.org/
are value statements not process prescriptions. The blood, sweat, and tears to create that type of alignment is how you pay your dues to achieve the benefits that proponents of agile methods offer. (faster, fewer defects) And in some cases your organization may not be able to fully implement an agile development methodology. It is not the "best practice" every one should adopt. In the end we must do what is necessary to create value for our organization in the current time and setting.
If nothing else agile methods should cause one to reconsider the value that any current practice or communication process brings to an organization and consider very carefully how "change" impacts the success of failure of your project.

Agile is not simple, and certainly not a quick fix. Rather it is a challenge and a cause to rethink and evolve our current current management and project management science.

My Agile Garden

I have a garden in by backyard that my lovely wife has been prompting me to work on. I tell her honey "it is an agile garden that's the way it is supposed to look". It is a flower garden, with a variety of perennials, a small tree, ornamental grass, vines, bird feeder with a water line, a low stone border. I know where all the flowers are and when they are supposed to bloom.
How ever no one would consider it an English garden with neat rows of precisely placed and cultivated plants. The ivy ground cover grew up and covered the trunk of the candy apple tree. I never planned that but it looked nice so I kept it. At the edge of my garden I noticed that one of the sunflower seeds from my bird feeder was lucky enough to germinate and grow into a sunflower plant. A more particular gardener would have pulled out this plant as a weed growing among the ground cover.
This was a special summer. I got a new daughter in law, Heather and she loves sunflowers. So I let it grow. It grew almost 4 feet tall and does not belong among the 6 inch tall ground cover. But it is like an unexpectd gift that has evoked many special memories. The wedding has past and the three blooms have gone to seed. I have been thinking about pulling it out as it still looks really odd. But sitting at breakfast I got one last kick from this plant. I just enjoyed the entertainment of pretty yellow finch trying to figure out how to get some of the seed from the big downward facing seed had that has lost all its blooms. That was a garden pleasure I would have missed if I put the sunflower in the compost heap when the bloom had passed.
This whole experience reminds me of some of the unexpected pleasant surprises I've experienced introducing agile project management in a setting where I worked many years ago.
I was leading a group of about a dozen developers and a handful of testers and writers in a group that was growing rapidly. I was serving as development manager and architect. But I was burning out and realizing that I was personally becoming the bottle neck of the development organization. It was this situation that first prompted me investigate and latter introduce FDD Feature Driven Development. My team was familiar with iterative development but this was the first time I used what is considered one of the real agile development methods. This was two years before the agile manifesto. My past colleagues at TogetherSoft will recognize the appendix in the object modeling in color book as our bible on agile. The ground was fertile for this agile seed to grow. I was blessed with good people to work with and adoption of FDD went well.
One of the key attractive points about FDD was it enabled us to scale and run multiple feature teams as the same time. I saw this as a way to enable my group to grow and adapt to the multiple ideas that were coming at us from our sales force and other technology partners. Yet it also provided me a framework to monitor and when necessary become involved and pull a "weed or two". See http://en.wikipedia.org/wiki/Feature_Driven_Development for more info on FDD.
But during the introduction of FDD to this group I had a pleasant surprise that I didn't really expect. I explained the process to my team and the various rolls I monitored and let folks pick up the various roles and responsibilities defined by FDD. I encouraged as much self organization as I could stand. Some reasonably expected things happened regarding who became class owners. But what I didn't expect was a young reasonably inexperienced engineer pick up the role of Feature Set lead. Before I decided to introduce FDD I was considering breaking the team up and designating leads for each of the sub teams. It never would have occurred to me to select this person for any leadership role. But to may amazement she took off like a star. She really blossomed and took over making may of the decisions I didn't have time to do. In many ways I think what she did was very much like the sunflower in my garden this summer. I hope she is doing well and I am grateful for what I have learned and continue to be reminded about the limits of what I can really control and what I need to let grow.

Agile patterns

I've been thinking about Agile lately as just a set of organizational patterns. There are two that gave me an ah-ha moment.

First -was in the book "How we Decide" by Jonah Lehrer. A fantastic book I strongly recommend to any one who thinks about how they think and what makes people do things. Near the end of the book he has an
antidote about a pilot and an crash that led the aviation industry to a process called cockpit resource management. (CRM) I believe that CRM is to the Aviation industry what Agile is to the software development industry. Unfortunately we've had many "crashes" in terms of projects that fail. Interesting thing is Lehrer goes on to talk about how CRM has gone on to the medical field as a practice that has yielded great benefits in the surgical operating room. And that was just one facet of the book. I believe that working on an Agile team or with a CRM culture is just so intrinsically satisfying. I just wonder why I feel that way about it that I find so cool. The accomplishment, the connection with others.... Humm. Perhaps a follow on book for Jonah Lehrer. A great example of what I'll call the shared owner ship pattern.

Second - last night I attended a Woodstock anniversary concert with the Cincinnati Pops and the rock band "Jeans n Classics". Very enjoyable and very talented people. What really struck me was how the Jeans n Classics folks all supported and complemented one another. They had a leader but each artist had special time to shine and show their own talents. The gelled as a team. Each song was a sprint and the concert was a project. I enjoyed the music and nostalgia. And I also admired the interdependent team. Each one contributing their particular talent. Usually at such a concert there a single star that is a focal point. This was a set of interdependent artists. Just like I'd like to see of a team of software developers. This is a great example of the interdependent pattern.

I think I'd like to develop this pattern idea some more. It helps to unify many of the ideas I've been bouncing around especially regarding the application of Agile to distributed organizations. More for another day.