Archive for the ‘Transitions’ Category

• Best Links of the Week – New Year Edition

  Date: 2010.01.05 | Category: Agile, Links of the Week, Scrum, Team, Testing, Tools, Transitions | Response: 0

  New Year links, a little late, but ready for your review.

  1. Defense Procurement Goes Agile – a summary from the Agile Process Leadership Network’s (APLN) October 2009  meeting describing how the DoD is moving away from waterfall to an iterative, incremental processes.
  2. Mixing it up with Agile & PMI – Orange County PM, Donna Reed, makes the claim that to be a successful Agile PM one needs to “move away from ACTIVITY-BASED project management toward VALUE-BASED project management.”
  3. Starting Scrum: What Would be the Logical Position of a Classic PM – SM or PO? – a Google groups discussion posed by a member with some excellent commentary.
  4. Synchronize Rather than Overlap Sprints - Mike Cohn explains why aligning Sprint end dates within one or two days of each other is a much better way to coordinate multiple Scrum teams.
  5. Agile Antipattern: Changing the Definition of Done – Bob Hartman discusses how the pressure to meet deadlines is simply “deficit spending” on your project with a bill that will get paid off sooner than you think.
  6. Welfare CSM Day 3: Experimental Mobiles & Rainforest Birds – interesting experience report about a different type of Certified ScrumMaster trainer; be sure to read the comments for additional insights and reflections by the other participants.
  7. UI Test Automation Tools are Snake Oil – an opinionated piece from Michael Feathers on the value of that expensive UI test tool gathering dust in your organization.

• I Really Hate CMMI

  Date: 2009.09.23 | Category: Agile, Lean, Transitions | Response: 0

  I came across a question on a usergroup asking the following (it’s condensed):

  “In our projects we maintain product backlog and do high level estimates in story points. Then when we actually start the iteration we do estimates in the sprint planning meeting in story points and then when the story gets completed we mark the actuals against it. Our understanding of story point is one ideal day (i.e.6 hours). Our estimate for the story include analysis, design, coding and testing. Now the CMMI group is recommending us that we should divide our story into analysis, design, development and testing substasks and track estimated and actual efforts against them. Their argument is that by doing this, there can be some data available which will tell us on how are we doing on each of this area and where we need to improve. For example if the analysis tasks are taking longer then estimated then we should identify reasons and actions to handle it. My argument was that we can not go below the story level because in agile way of working analysis, design, development and testing is kind of merged into a story  and since the story is a smaller piece its not possible to break it further in such a way. I told them that this will be too burocratic and there will be lot of administrative overhead. The CMMI group told me that in their previous implementations they have done it only this way even in organizations where they are using agile methodology (Scrum, XP etc.) and this was the only way they could find to handle this situation.”

  There are so many things wrong here, I will just highlight a few.  Having worked at a CMMI ranked company, from perspective of a contributor most of these rankings are pure bunk.  The CMMI ranking had absolutely no impact on the quality of the system delivered or the timeliness of our delivery.  In both aspects, the CMMI process produced a lower quality, more costly system than an Agile approach.  As applied at this company, CMMI only served to reinforce all the bad habits and waste of waterfall (I really hate the term waterfall since it is SO pejorative.  Just exactly who admits to doing waterfall? – CEN).

  When I hear the phrase “this was the only way they could find”, it just sets off warning bells in my head.  My only advice is to trust your instincts in resisting the mindset from the CMMI auditors. From the short description, it seems to me they are trying to create mini-waterfalls within an Agile process. As for the improvement the CMMI auditors are looking for, they are simply suboptimizing by focusing on tasks – that is such Taylorism.  I am reading an excellent book by Craig Larman and Bas Vodde talking about using Lean thinking to scale Scrum to larger product organizations.  This book provides the intellectual firepower to destroy the last vestiges of the waterfall in modern software development.

  From my experience of CMMI and talking with some auditors, in many instances you only need to show evidence that a practice is occurring in order to pass an audit. There are many legitimate and creative ways to provide evidence your are following the practices described in CMMI. If your instincts are telling you the auditors are wrong, trust them.  Learn what the auditors are looking for and work with them to provide the same information.  Don’t let their intellectual laziness strangle real change and innovation in your organization.

  As a practical matter, you need to placate these CMMI folks because they obviously have the attention of management. I would try to understand what management is looking for with a CMMI rating – beyond the obvious we need a ranking to get more and bigger contracts. What advantages would it give the business? How would you know that the organizational change caused by CMMI is producing the effect your company seeks? Then I would show your management how Scrum is helping in some areas and where it is deficient. In the deficient areas, maybe CMMI can help. Perhaps the CMMI people are right and the processes are unstable. Think about what you could be doing to make the entire system more predictable (hint – think Lean, not CMMI).

• Dog Psychics for Your Agile Team

  Date: 2009.09.21 | Category: Agile, Communication, Conferences, Transitions | Response: 0

  I was having a really interesting conversation with Susan Elliot Sim at Agile Open SoCal.  I was asking her why is it so difficult to get peer-reviewed articles published on Agile.  She responded by telling me this story, with the instruction to identify the emotions you feel when hearing\reading the story:

  “Suppose I told you I was going to tell you that in order to understand what is wrong with your dog – he’s been limping and you think something is wrong with his leg – we are going to take him to a dog psychic in Nevada and this dog psychic is extremely good, highly recommended and gets great results and you take your dog there.

  You ask the dog psychic, ‘Can you ask the dog if his leg hurts?’.

  The dog psychic talks to your dog and turns to you to say – channeling your dog, ‘Well…thank you for asking about my leg, but that is not what’s bothering me.  It’s my back.  It hurts a lot when I jump up and down off the bed, especially on cold mornings, so could you please get me a ramp to make that easier?’

  ‘Also, I really like it when you come home to play with me during the day and I remember that time we went to the park and chased the birds in the pond, so let’s do more of that.’

  ‘Oh, and I really don’t like that dog food we have been eating all these years.  Yes, I know that I eat it all up and I probably shouldn’t have, but I didn’t want to hurt your feelings cause you do so many nice things for me.  However, since we are finally having a conversation after all these years, I thought you should know.’

  And you respond to your dog, ‘Oh my God!  I never knew you felt this way about so many things.  When we get home, I am going to make all these changes.  I am so glad I spoke with this dog psychic!’”

  So how did you feel after hearing this story?  It is a bit farfetched isn’t it?

  According to Susan, this is experience is very similar to what academic researchers think about Agile – it is nothing more than dog psychics.  That you really have to believe in dog psychics in order to get any value out of them.  In addition, the people who believe dog psychics sound a bit evangelical in talking about how great dog psychics are and yet there is no (scientific) evidence on the mechanics of dog psychics.  I thought this anecdote is a really good concept to keep in mind when we encounter skeptical people; sometimes we just sound loony.

• People Over Process

  Date: 2009.04.06 | Category: Agile, Transitions | Response: 0

  Max Pool has a great post today on his site highlighting the importance of people in making an organization succeed.  This is one of the reason why this statement leads the Agile Manifesto (it is interesting that I keep coming back to this concept – CEN).

  “Individuals and interactions over process and tools”

  I just want to amplify what Max says – when you act at work to make things better, you choose to improve your organization.  When all you do is sit at your desk and complain to your peers, you choose the status quo.  At some point we have to ask ourselves if we continue to do nothing against the status quo, when do we become enablers of it?

• Letting Go of the Past

  Date: 2009.02.23 | Category: Agile, Coaching, Team, Transitions | Response: 0

  Sometimes when I meet with people who want to do Scrum (or anything Agile), they have a hard time looking beyond the past to a new way of making products.  They resist any change to the way things are done because they are often times too wrapped up in their old patterns of behavior.  I understand where this form of resistance originates – these individuals have been so involved with their the organization and its dysfunctions, they have forgotten that things can be different.  They have forgotten that things were different some time ago and their organization used to be “cool”.  What many people do not truly understand is they really do have the power to make their organization “cool” again and that if they really want something to change, it will change.

  It is no mistake that the very first line of the Agile Manifesto reads:

  Individuals and interactions over process and tools

  One of the main themes in Agile is about individuals making a better professional life for themselves.  Apart from our families, our professional life is the second largest use of our time on this planet.  The relationships and interactions we have at work have some of the most far reaching influences over our lives, yet we all act as if we are passive actors in our professional lives.  If we are unhappy about our work life, we own some of responsibility for current state of affairs.  The powerful thing about Agile is we can decide to make the future better.     

  In a recent example, I was coaching a group of programmers on how they can use Scrum to develop a new product.  They were very early in the development of their project and we were trying to reach a consensus of  how we will work together in the future.  I was struck by how many of the obstacles they were discussing which were result of “marketing”.  If “marketing” only did this or provided us with that or gave us what we asked for – you get the picture.  It’s not us that have the problems, its them.  While there was some truth to their analysis, but as in any good dysfunctional relationship both sides share equal blame for the situation.  What I found surprising was these programmers had ceded all their power for change to “marketing”.  If you believed them, nothing would change until you got buy-in from “marketing”.  As a result, they were stuck.  

  I think I made a breakthrough with these folks because by the end of the workshop, they were very interested in finding measures which helped them see if they were on the right track for change or off in the weeds.  Anytime the participants in a workshop want to stay for a couple more hours to define metrics is sure sign of ownership.

• Agile 2009 Submissions

  Date: 2009.01.22 | Category: Agile, Conferences, Design Excellence, Design for Six Sigma, Product Owner, Transitions | Response: 0

  Agile 2009 is accepting submissions.  This year I really feel I have something unique to bring to the larger Agile community, so I submitted two proposals - Product Design Tools for Agile Product Owners (on the Agile Product Management stage) and Charting the Agile Transition (on the Agile Adoption stage). Both build off of my recent work looking for the best tools from the Design for Six Sigma world to apply on Agile teams.  Please feel free to comment on the Agile 2009 website if you have any feedback.

• QFD & Agile Process Roll Out

  Date: 2009.01.06 | Category: Agile, Agile SD, Collaboration, Design for Six Sigma, Presentations, Scorecards, Transitions, Voice of the Customer | Response: 0

  I have been wanting to blog on my last presentation at XPSD for a while, but have been so busy with the Holiday Season – so here are my thoughts on how to use the Design for Six Sigma (DfSS) quality function deployment (QFD) tool to gather the Voice of the Customer data around creating a customized Agile process for your organization based on the issues your organization faces and deriving meaningful measures which will allow your group to monitor and track the roll out.

  Step 1 - The first thing you need to do is collect the Voice of the Customer (VOC) about what you want your new process to do.  So, to look forward, we need to look back for a little bit.  Gather all the people who will be participating in the process change and ask them some variation on these two questions:

  1. What is your biggest pain point with the current process?
  2. What is the number one thing you would change about the current process?

  To gather the VOC data, I used the Wall of Wonder - allow people to work in small groups quietly for a few minutes, capture each comment on a Post-it note and hang them up on the Wall.

  Step 2 -The next step is to group the VOC data into logical categories using an affinity diagram.  I find the best way to do this is ask the participants to get out of their seats and rearrange the items on the Wall of Wonder until everyone is satisfied with the groupings.  In DfSS parlance, each of these categories is called a user need.  A user need is simply trait the new development process must satisfy in order to be considered successful.

  After we have labeled all the groupings, I ask the participants to force rank the user needs with the most important traits of the new process receiving the highest ranking.  In my example, addressing issues surrounding requirements and adequate resources were the highest priority for the new process.  You can also rank the user needs from 1 to 5 and allow some user needs to have equal wights.

  Step 3 - Once we have ranked user needs, we enter them into the rows of the QFD chart (Room 1 in DfSS language).  Either as a big group or smaller work teams, I then ask the participants to think about what sorts of requirements the new process must have in order to meet our user needs.  This is the point where someone (usually an engineer) gives a solution to the problem and I need to remind the participants that requirements are solution agnostic.  The requirements are then listed as columns along the top of the QFD chart (Room 2).  Requirements are allowed to fulfill more than one user need, but more on that in Step 4.

  Step 4 - OK, we have our user needs which define the characteristics that our new process must provide our organization and we have requirements that fulfill those user needs.  How do we make sense of the requirements and find out which requirements are critical to the success of our new development process?  Or put in the language of DfSS, what requirements are critical-to-quality (CTQ)?

  To find the CTQ, we first need to complete the interrelation matrix between the user needs and the requirements (Room 3).  For each requirement we need to identify the degree they are related to each user need using the scale of 9 (strongly related), 3 (moderately related), 1 (weakly related) or 0 (not related).  It is best not to spend too much time discussing each of the relationships since they are a lot of boxes to fill in, so a tool like Planning Poker helps move things along.

  Step 5 - Next we rank the requirements by multiplying the interrelatedness score of each requirement with the user need ranking in each row and sum each requirement-user need product into a total at the foot of the column.  This example shows how we arrived at the total of 162 for the “on-time delivery” requirement:

    Total = [3 x 8] + [9 x 7] + [3 x 6] + [9 x 5] + [0 x 4] + [3 x 3] + [0 x 2] + [1 x 3]
          = 24 + 63 + 18 + 45 + 0 + 9 + 0 + 3
          = 162

  Repeat for each column to rank the requirements from high to low.  The requirements with the highest score are the CTQ and are the MOSTimportant requirements our process must fulfill in order for the roll out to be a success.  Or put another way, these requirements provide us the most leverage on making a successful product for our customers.  If we cannot meet these requirements, it does not matter what process we use – we have a very low probability of making a product that will satisfy our customers.

  Step 6 - The final step is to derive our measures that allow us to monitor our CTQ with a scorecard.  In order for measures to be meaningful, they need to tie to something that the organization or customer (this even better) cares about.  It is time well spent to create the measures as a group and reach consensus that the measures are indeed meaningful and what the organization chooses to evaluate itself against, otherwise people will game the scorecards and there will be no accountability.  I find it useful to have about 50% of the measures tied to the customer so they process is grounded in the market.  Too much process transformation is done for the sake of the organization and the improving the customer or the bottom line is often an afterthought.

  So where’s the beef?  Really – the word Agile has not even been mentioned up until this point.  Actually, that is the point.  A lot of Agile transitions start out backwards – we want to do Scrum\XP\whatever, so let’s find our problem.  QFD says let us examine and analyze our problem, find out what is most important for US and monitor those items with a scorecard to know if we are on track or not.  This approach is superior because once we have the QFD and the scorecard, we can then begin to think about what Agile process and\or practices that allow us to meet our CTQ and enhance our measures.

  Maybe for your organization, you have a CTQ around requirements, then perhaps you can try our user stories and see if they move your metrics?  Perhaps you have another CTQ around quality, then maybe having cross-functional team moves that metric?  The beauty of the QFD is it allows you to mix-and-match to meet your objectives, not what it says in some book.  At least now you have thoughtful information to help you tailor your Agile approach and an objective way to know if the change you are making are having the intended affect.

• Agile Transitions Workshop

  Date: 2008.11.13 | Category: Agile, Agile SD, Design for Six Sigma, Presentations, Transitions | Response: 0

  I am quite busy with the presentations lately.  Next up is an appearance at XPSD on December 4th where I will run a workshop showing how to use some simple tools to chart and monitor an Agile transition for your organization.  This will be a hands-on session.   The tools I will be demonstrating come from my Design for Six Sigma work.   Look forward to seeing you in December!

• It’s 2008,

  Date: 2008.10.29 | Category: Agile, Conferences, Transitions | Response: 0

  … and the time for guerrilla Agile is over.”

  Or so says Gil Borza from Industrial Logic at his talk at SD Best Practices titled “Secrets of High-Performance Agile Implementations”.  Gil’s position is Agile has proven itself in enough places and on enough projects that we should not hide the fact we are doing Agile anymore and just do it.  If you can’t do it, then change your organization.

  One of the interesting refrains I heard regarding Agile transitions was the need for executive-sponsored Agile transitions teams with charters, budgets and authority to remove organizational impediments.  It was clear from many of the consultants that organizations who are successful with Agile transitions are the companies who put real money behind these initiatives, run transitions as change management programs using traditional project management tools and invest real money into their staff in the form of training and reduced productivity as the organization learns new skills and behaviors.  Real goals and milestones on what the organization should look like in 6-12-18 months are established and people are held accountable for their progress.  Giving everyone a copy of Kent Beck’s Extreme Programming Explained or Ken Schwaber’s Agile Project Management with Scrum and saying, “OK, now you are trained.  Go do it.” ain’t gonna cut it.

  As for the practical side of things, rarely does a mismash of cherry-picked Agile practices work.  Eventually whatever you left out – pair programming, automated testing, lightweight documentation, cross-functional teams, stand-ups, etc. – will come back to haunt you later and kill your productivity.  It is very important in the early stages of the transition process to select teams and projects that are appropriate for the Agile approach.  When you are fixing bugs, there is just not that much to learn about how to be good at Agile.  If you think a team trashing around with legacy issues as there first Agile project will be a success, you are deluding yourself.    Once you have got over that big hump of learning, then you can extend Agile to parts of your organization that are tightly coupled to each other and perhaps tackle those nasty legacy bugbears using a SWAT team of your best technical and business folks.  Another thing to keep in mind, co-locate your teams\product communities as much as possible and don’t break up the communities.  Keep people together with the product.  A lot of time and money was spent investing in these growing and nurturing these communities (I like to think of them as corporate assets) and reallocating “the resources” when a project is done just pours all that money down the drain.

  If you are serious about an Agile transition, recognize that every part of the organization that touches software development will have some type of change.  An Agile transition is trying to incrementally change the habitat in which an Agile team resides and to do that you need executive sponsorship.  Oh, if you lose your sponsor, you’re done (until you can find a new one).  Finally, expect to wait about a year before you start realizing the high productivity levels promised by Agile processes.

• Mistake Museum

  Date: 2008.10.29 | Category: Agile, Conferences, Transitions | Response: 0

   

  Here are some common mistakes people make when trying to make their organization more Agile from Rick Brenner and Nancy Van Schooenderwoert.  My comments are in italics.

  • Underestimate the politics of the organization.  Avoid this trap at your peril.  As Ken Schwaber likes to say, “A dead sheepdog is no use to the team.”
  • Use an Agile process to run the Agile transition.  Use tried and true change management techniques from the project management world.
  • Allow the internal auditors to credential the Agile process.  Frequently internal auditors do not know what they are dealing with when confronted with an Agile project.  My experience is they often gum up the works to make their lives easier.  While these people are normally trouble, learn what they need.
    
  • Scale up rapidly after a few successful pilot projects.  I call this early institutionalization or freezing the transformation process in an immature state.  You would never eat a green strawberry, so why push an immature system to your entire company?  Learn why the pilots are successful and amplify those factors while diminishing the obstacles.
    
  • The early pilot projects are not run like projects; there are no goals, budget or customers.
  • The “wrong” project was selected for the Agile team; i.e. legacy systems, unavailable customers, ill-defined goals, etc.  Agile teams need to work iteratively in close collaboration with a customer who cares about the project and has the authority to make decisions.  Anything less causes “issues”.
  • Select team members who are actively hostile to Agile. Agile relies on the goodwill of the participants to try new things in order to succeed.Skepticism is good, but too much makes the whole thing a farce.
    
  • Treat people as interchangeable resources and swap in-and-out at will. Agile asks people to make commitments by encouraging them to take ownership of products.  How much ownership do you really have when you are on four different teams?