First deadly sin of #Agile

I’ve always thought that for all that Agile got right, it almost got the same amount wrong. And most of what it got wrong had to do how it distanced the client from the project team.

Surprised?

Remember that although Agile was promoting co-located teams, the clients certainly had a different status than the other members of the project team. I’m still amazed that the Scrum segregation of clients and team members into chickens and pigs is tolerated. The basic premise is that although the clients are interested in ‘breakfast’ they aren’t as committed as the ‘pigs’. This of course is ridiculous and in many projects the clients have more on the line than the development team. But the most disappointing thing is that Agile seemed to inherently promote a hierarchy. Even outside of Scrum, Agile still seemed to confuse who defines value and the project team typically over steps their bounds and decide for the client. For example, the No Estimates movement deems Estimates a waste repeatedly although the only people who can determine what is waste are the clients.

Semantics

Much of this can be tied up in Semantics. The terms of Client, Customer, Business User – all separate.

It wasn’t until we were talking terminology in a more traditional project structure that we decided there was a much more appropriate term:

Colleague – ‘A person with whom one works in a profession or business.’

Or even better, from the Latin collega or ‘partner in office’. Finally a term that does not imply a hierarchy and instills the promise of a partnership working toward a common goal.  All colleagues working to create the highest quality solution to a problem.

Colleagues delivering frequently to minimize Inventory and shorten Feedback Loops.

Now that is Agile.

 

Advertisement

In #PID I Trust #Prince2 #PMOT

I’ve been using Prince2 as a methodology at the University of Manitoba for almost a year now and I’m quite impressed. As a methodology it is quite good and focuses on the right things. Prince2 recognizes that a project initiated well sets a project up to succeed. There three things Prince2 does during initiation that I feel set it apart from other methodologies.

Project Initiation Document – PID

The PID or the Project Initiation Document is the main initiation document in Prince2. We commonly refer to the PID as a Project Charter on steroids. The table of contents for a typical PID contains the following

• Business Case
• Project Definition
• Product Based Planning
• Project Approach
• Project Governance and principles
• Quality Management Strategy
• Risk Management Strategy
• Organizational Change Management Strategy
• Organizational Capacity Management Strategy
• Project Plan

As you can see from the table of contents, the PID is a much more in-depth document and agreement than the typical project charter. It also more of a strategy document than project charter by getting the project team to discuss and document strategies for Quality Management, Risk Management, Issue Management, Communication Strategy, Change Management Strategy, and Capacity Management Strategy.

There are two sections of the PID that go right to the strength of Prince2

Project Governance

One of the main strengths of Prince2 is the Project Governance and formal Project Board structure. In Prince2, the Project Boards makes all the decisions for the project and is made up of the following three roles:

• Executive – Main sponsor or project champion – typically provides the budget
• Senior Supplier – typically provides the resources for the projects
• Senior User – typically will use the solution operationally when complete

These three roles are unique compared to other methodologies and it really serves the project well to ensure that all decisions are made in a balanced and thoughtful way. The really unique part of the Project Board structure is allowing for a seat at the table for the Senior User. Typically the users of the solutions don’t have a leadership role and only get involved for requirements definition and testing. By getting involved earlier, the Senior User has the ability to guide the vision of the solution. In my experience, this really allows for great value being delivered and fewer subsequent enhancement requests that are required to make the product useable. 🙂

Product Based Planning

Perhaps one of the most valuable Prince2 concepts is the Product based planning. This term refers to the Prince2 focus on what products the project is going to produce. Prince2 has a deliverable named Project Product Description. The Project Product Description is intended to describe the ultimate product that the project will produce. This deliverable helps to focus the project team to describe what project success will accomplish before defining detailed requirements. This process is very helpful and helps to create a shared vision across the project team. Prince2 then tasks the project team to define the interim product descriptions that are needed to ultimately create the Project Product Description. These Product Descriptions could be documents, demos, prototypes, or anything that is created during the project. A Product Breakdown Structure is then created to define the order the products and sub-products are created in. This Product Breakdown Structure is an excellent vehicle to uncover dependencies without having to create a detailed work breakdown structure.

By creating these three descriptions/documents, a lot of clarity is provided to the project team on what will be accomplished, what interim steps and documents are needed, and what order the project team will create them in.

Agile?

Right now, I bet you are wondering just how top-heavy and cumbersome Prince2 is. The real benefit of Prince2 is that these deliverables can be detailed separate documents or a few paragraphs in the Project Initiation Document.

Prince2 has two principles that align it with Agile:

1. If you don’t customize Prince2 methodology then you are doing it wrong. The customization of Prince2 is one of the 8 foundational principles of Prince2
2. Prince2 is perhaps the only Manage-by-Exception methodology I have seen. There is a section in the Project Initiation Document that defines the acceptable tolerances for the project. Only when the project goes outside these tolerances, does the Project Board need to be involved.

So Prince2 formalizes space for the project team to work and not be micro-managed.

Sounds more Agile than Scrum if you ask me…

My #Agile Breakup

So it has been 11 months now since I’ve seen Agile. How has it been? To be honest, I haven’t missed her. I really haven’t. What has been made clear is what Agile is and what she isn’t.

First Date

I guess Agile and I started dating in 2006. We both were interested in each other and then I was able to arrange for Yves Hanoulle to be the keynote at the Software Development and Evolution Conference I was helping to organize in 2011. Yves had a great presentation on the Agile Mindset that was brilliant. I must admit I only realized how brilliant in the last few months. I think I did what many people have done when they encounter an attractive person coming out of a bad relationship. I moved too fast and fell too hard after being with Waterfall for too long.

The Agile I met was a collection of interesting, valuable methods. There was the concept of the Agile Mindset that Yves and others were promoting with wisdom. But I fell into the same trap as many others. I was going to propose to Agile and she would be the only methodology for me. All projects would be Agile. If clients didn’t like my new girlfriend, then they could go elsewhere.

Agile was a Methodology. I was sure of it. I would exclude using all other methodologies while Agile and I were serious. I would create an Agile Methodology by combining methods and practices. I would read and author Agile papers and presentations where we routinely challenged and chastised each other for not being ‘Agile enough’. I looked for the Agile complement for all waterfall or traditional methods. No matter the project, I promoted the Agile method.

For those of you keeping score at home, the PMBOK isn’t a methodology as well. Similar to Agile, it is a listing of processes, procedures, and knowledge that can be applied. But it is not prescriptive and does not provide governance on how to apply the methods and practices. Many companies take the PMBOK components and create their own methodology from it though.

But what about Scrum you ask? I’d say Scrum is an incomplete methodology. Although it does provide a methodology for the iterations on a project, it does lack guidance and governance in relations to the business case and pre-project intake process. Scrum also lacks guidance for the larger portfolio and enterprise governance concerns.

My Agile Mindset

My mistake was trying to take a collection of methods and assume a methodology exists. A larger mistake was then losing my Agile Mindset of constantly questioning the Agile methodology for value. That is my biggest complaint about Agile now. Many proponents seem to have lost the Agile Mindset of constantly questioning the best method to use on each project. Everyone is just promoting more and more ‘Agile’ methods without confirming that the method returns the most value for the clients. See the No Estimates discussion for this. To blindly promote no estimates for all clients does not represent an Agile Mindset.

I was going to say I’m just as Agile now and I was before, but that statement shows a non-Agile mindset – Agile is not a methodology to achieve. Let’s just say, I feel my projects achieve the maximum amount of value for client by using the Prince2 Methodology using Agile methods and practices were appropriate. Everyone I’ve worked with sees the value in Agile methods and are eager to work with them. The concept that you have to buy the entire Agile Methodology to use an Agile practice is misguided.

I mention Prince2 because that is what we use at the University of Manitoba. You could replace it with whatever you use at your company and then search where you could use Agile methods to return more value. The more I use Prince2, the most I think it is one of the best methodologies I have used though. Highly recommended.

Use an Agile Mindset, Agile isn’t about the Methodology it is about getting better little by little.

 

Does #Google hate #Agile

I came across this post about how Google thinks Agile development is nonsense by Michael Church. You can check out the article here.

Where to start?

Ok, lets start at the beginning. It appears Michael Church has made the leap that Agile is Scrum and Scrum is Agile. That is quite the leap and one that I disagree with. I myself have had a couple of posts on why I don’t believe Scrum to be an optimal method. Of course, I would never say Scrum is nonsense.

What else?

“It’s a culture of terminal juniority. Product development and architecture aren’t the programmer’s job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level “user stories”. This is OK for a junior who’s learning the codebase and software engineering principles and may appreciate the guidance, but anyone with more than 5 years of experience is going to find it to be a dissatisfying way to work. There is no place for an actual senior engineer on a Scrum team.”

I would say that Michael has never been on a well-run Agile team and doesn’t understand User Stories. User Stories are designed to include Architecture issues and deliverables. Certain frameworks like Disciplined Agile Delivery actually formalize this role as well. The two-week limit doesn’t need to be adhered to like a commandment. Some exceptions should be made. For someone who has worked at Google like Michael, his lack of Innovation seems to be adhered to solely for the sake of the article. If the Scrum process doesn’t fit, change it. I find it hard to believe Google doesn’t innovate like this elsewhere.

“It’s aggressively short-term, by design. These methodologies are designed for scrappy, unproven consulting firms that need to bear down and pass their first high-profile project. In that context, they probably work– at the expense of technical debt and tired workers.”

Not sure where Michael gets this opinion. If anything, Agile is the one framework that is focused on sustainable pace and ensuring that technical debt doesn’t get built up and people don’t work excessively. User Stories are not just for user functionality, technical debt gets added there as well to ensure it is addressed as part of the sustainable process.

“It has no regard for the programmers’ career needs or desires. See the points above about Agile’s short-term orientation. Now, people are willing to give up their career goals to pitch in on a short-term crisis, for two reasons. First, if it’s genuinely important to the firm, then it does help their career to do so. Second, a story of having solved a genuine crisis under time pressure can be a career booster. Saying, “I was in the War Room and had 20 minutes each day with the CEO” means that you were important and valued. Saying “I was on a Scrum team” means “Kick me”

Wow. Again Agile is the one movement that talks about respecting people and having people choose what they work on and where their career is going. The concept that Agile is only for short-term crisis mode is a falsehood that Michael can’t seem to let go. And trust me, just being in the same room as a CEO doesn’t mean you were important. It sometimes means he doesn’t trust you.

“It’s micromanagement. User stories and backlog grooming are there to control what the engineer works on. The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking. The story points are there to track productivity (in some superficial, inaccurate way). The talk of “removing impediments” is code for “spotting slackers”. Even for people who have nothing to hide– even for people who’d be strong performers in a more sane, relaxed, progress-over-rapidity organization– a surveillance state is an anxiety state. It sucks, and if you’re good at what you do, it’s insulting to have to justify days and sometimes even hours of your time, and to be jerked around if these estimates are even slightly displeasing to the “product owner”

Absurd. Again the developers pick what they work on so there is more control that someone assigning tasks in a traditional project. Michael, I think thou dost protest too much. 😉

“At identifying low performers, it has an unacceptably high false-positive rate. Let’s not kid ourselves. The reason “Agile” is so popular is that it carries this mythology of spotting low performers immediately– in two weeks instead of over months– and giving objective cause to fire them. (Agile/Scrum is, in essence, a permanent PIP.) I’ve heard it put this way: “use Scrum to spot your Scum.”

OK, I think we will leave it there as subsequent points are along the same line. I have never heard of anyone promoting Agile as a means to spot low performers.

I’m not sure what the motivation is for Michael writing this article, but I do know three things:

1. Agile is not Scrum
2. Michael has not been on an Agile team and would benefit from that context before writing on something he does not know about. Me writing on how Google teams are organized similar the Lord of the Rings Fellowship would be equally as uninformed and wrong.
3. The article reads almost like a ‘shot across the bow’ of Agile being used at Google. A warning to not use it or bad things will happen with developers leaving. A good dose of Fear, Uncertainty, and Doubt.

Hate to break it to you Michael, but with Google promoting code thousands of time a day, you are already very Agile! I recommend reading about other Agile methods and suggest changing Agile methods to suit your needs. I know Google has the ability and track record.

BTW, the client engagement and customer focus of Agile may just have avoided that whole Google+ thing…

Just Sayin’

#Scrumbled #Agile or #Disciplined #Agile

So I attended a Scrum session last week that was presented by Steve Porter. Excellent session that discussed many of the misconceptions or myths about Scrum. I came away wondering why I don’t profess to believe in Scrum. I honestly do follow many of the Scrum rituals, but I always seem to not be able to follow them completely. The processes I use always seem to be a Scrum-but implementation. I do Scrum except for this customization, I do Scrum except for this circumstance. Many of the myths we reviewed also seemed to be focusing on small misconceptions of what Scrum is. Not the large issues that could really derail a project – this frustrated me.

For example, we discussed whether the iteration planning should be 4 hours for a two-week iteration. My response is that it is nice to have a guideline, but things will take as long as they take. Sometimes we need to change based on the team and the stories.

Honestly

To be honest with you, the one thing that has always bothered me about Scrum is the amount of time, effort, and care that focuses on the rituals themselves. There tends to be great detail in how long meetings should be, how long iterations should be, what a Product Owner should do, and what a Scrum Master should be. Early on for Agile projects, I think this type of direction can be quite helpful. But Scrum has always struck me as being overly precise and prescriptive. In many situations I would prefer a loose guideline that would provide me options as to how I could structure a project. It really feels wrong to try to control an Agile project to the extent the Scrum process does. I would much rather just allow my team to customize the process as they see fit.

One thing that resounded with me after reading “Creativity, Inc.” was the comment that to nurture a creative culture, we need to “hold loosely onto goals and firmly onto intentions”. If you allow me some creative license, I believe this can be translated to than we need to “hold loosely onto rituals and outcomes and firmly onto values”

Stated in this way, it becomes clear to me why I struggle with Scrum.

It always seems to me that Scrum places rituals ahead of values. Instead of focusing on values and discussing a variety of approaches, Scrum doesn’t spend enough time discussing values and spends more on the details of rituals.

To me it seems we have Scrumbled/Scrambled what Agile should focus on.

What to do?

Recently I’ve become more aware of Disciplined Agile. I believe it has great value that is not found elsewhere in the Agile Ecosystem:

• A Decision Framework that provides a structure on how an Agile project can sit inside the Enterprise and doesn’t just focus on the Software Development Team
• A Decision Framework that allows for the customization of the Agile project process based on the readiness of the Enterprise and project team. Disciplined Agile supports the following Agile processes:
  • Agile Delivery
  • Lean Delivery
  • Continuous Delivery
  • Exploratory
  • Program Management
• A Decision Framework that provides a prioritized list of rituals/deliverables to use though out the project
  • This allows for the project team to choose and adapt to what fits best in each circumstance
• A home for an Architecture Role on the leadership of an Agile Project
• A Decision Framework that provides the right focus for lightweight models/documentation through out the project

I’ll be focusing on Disciplined Agile over the next few Blog posts. It has great promise in helping Agile take that next step into the Enterprise.

#Agile means never saying never and always saying maybe – #Agile #Inertia

Recently at a few Agile discussions I have noticed people saying things like:

“You should never provide estimates”

“You should never start to code without automated tests”

“You never need Business Analysts or Testers”

“You should never create requirement documents”

To me, Agile at its heart is always seeking to understand first. Many of these absolutes are diverging from seeking to understand. They even remind me a little of the waterfall method and the absolute rules that were in place that defined the mandatory deliverables that needed to be in place.

Now while I would agree that most of these statements are true most of the time, if you are not modifying your approach with each and every situation and client, I would suggest you are not Agile. If you are executing iterations and you can’t respond to a request from the client on how you execute iterations, then you probably aren’t Agile. If you read the book of Agile and can’t respond to a client request to have requirement traceability, then you probably aren’t Agile. Remember that Agile is being able to deliver the most value to the client and the client defines that value. Not you, not the Agile Manifesto, not bloggers, and especially not me. 🙂

Dictionary.com defines Agile as “quick and well-coordinated in movement”. The antonym of Movement is Inertia. If you have Inertia to move, change, customize, or adapt Agile methods, then I would suggest you are not Agile. To be Agile, you need to be without Inertia. Is Agile Inertia better than waterfall Inertia? Of course it is. But it is still Inertia and it is preventing you from delivering maximum value to your client.

Without Inertia means you are able to move between situations based on what fits that situation. Perhaps that is why I have problems with Scrum and the Core Protocols. I don’t think either provide the freedom to allow people to be truly Agile to tailor the approach to best fit the client and deliver the most value to the client.

If you have been delivering multiple Agile projects using the same methods and procedures then I have some bad news for you. You may have developed an acute case of Agile Inertia. In fact if you have been delivering subsequent iterations using the same methods and processes then you probably have a mild case of Agile Inertia.

Sadly there is only one cure for Agile Inertia. Never say never and always say maybe.

#Agile Perfection musings

One of the many toys my kids got over Christmas was the game Perfection. I can remember playing this game many times when I was young and I was happy to see my kids take a liking to it. For the uninitiated, the game of Perfection involves matching plastic shapes with their appropriate match on the board before the timer runs out and the spring releases the board and shoots all the pieces in the air. Good old-fashioned fun. Funny thing is that the game has not changed over the years other than introducing subtle mirror image shapes to confound adults who think they have the game figured out. 😦

While I was playing the game with both my children, I couldn’t help to try to instil some Agile principles in their thinking. But to my surprise the kids already were playing the game with the smallest iterations possible. Instead of trying to create batches of shapes to place, they both instinctively took a piece at a time and tried to place them before looking for the next piece. I instead watched them with fascination as they tried to become more efficient by implementing some more traditional processes.

A couple of these were:

• One interesting observation came with my son. He soon discovered that he could be more efficient if he batched 2-3 pieces in his hand at a time. Fewer pieces than that and he found that there was too much motion to get the pieces and forgetting of where the matches were on the board. More pieces than that and he spent too much time searching through the pieces in his hand to find the one he was looking for. This was quite fascinating as the process he used was sometime looking on the board first to find a matching piece if he remembered it was one of the batch he had just picked up. So to save on motion he sometimes went from hand to board and board to hand if he recognized he had another match in his backlog.
• Another interesting observation then came with my daughter. My daughter is much more results focused and really disliked the game popping on her. Her first solution was just to add more time to the game so it didn’t pop. 🙂 Once I mentioned that this wasn’t really in the spirit of the game, she then focused on another angle. She focused on the pieces that gave her the most problems and was sure to do those first. Interesting. My 5 year old daughter just performed Risk Mitigation on her Perfection project. Awesome.

So what does this have to do with Agile?

Good question. The game of perfection is at its heart a game about problem solving just like Software Development. And I think the observations about how to be efficient at Perfection can provide some insight in Software Development and Agile Software Development in particular.

If we wanted to complete the comparison to Agile Software Development one could look at the following analogies:

1)      The Perfection Board can be thought of the entire solution for the project

2)      All the shape pieces are the entire backlog of User Stories for the project

3)      The small number of shapes in hand is the iteration backlog

4)      The placing of the shapes in the board is the iteration itself

 

This leads to the following observations on the process:

1)      Creation of small batches can provide additional efficiency

When the process was matching a shape one by one, there was a lot of movement from the board to the backlog of all the shapes. There was more physical movement and it was harder to remember the location of the pieces on the board AND in the backlog to find the required shape. Once small batches were created, it became apparent that the small batches helped to minimize the amount of motion AND help in the memory of the location of the pieces. Although the board was still the same size, the ability to locate the piece in your hand was much easier. It is much easier for a human brain to focus and remember 5-6 items versus 30 items.

In addition, the small batches provided feedback on our progress throughout the game. You got a much better sense on how you were doing by the duration of the iteration as compared to prior ones.

Iterations assist in minimizing movement, providing focus, and maximizing feedback.

2)      Creation of small batches can group like items together further saving on motion and possibly waste.

One thing that certainly increased the probability of success was when you had successive pieces that ended up being located beside each other on the board. I think this is very analogous to planning User Stories on a project. If you can group the User Stories together in the same iteration, it should save on rework that might be required if you did them separately. In addition, it will also save on subsequent context switching to understand that aspect of the solution again in the future.

I am taking artistic license here by comparing the physical movement of the piece to proper spot on the board to the act of understanding the context of that area of the solution and proposing that adjacent solution areas may impact one another.  So revisiting areas can cause additional work to gain context and also possibly cause some rework.

In addition, other groupings like risky or hard items can also provide additional value.

Not all User Stories are independent and interchangeable, planning is required

3)      Measurement, feedback and learning are critical to any process

 Measurement, feedback and learning are critical to being better. Although the popping of the board is a negative event, it was a key driver to getting better. I’m not sure my kids would have been focused to improve if there was no reason to improve. (although I would have preferred positive reinforcement versus negative reinforcement.) To become better and more efficient, measurement is required. Without providing goals and measuring performance against those goals, we may never have achieved the innovation in our process.

 Goals and Measurement are required for Innovation, but they cannot lead the process. The goals and measures must be managed by people, people should not be managed by goals and measures.  

Summary

At the end of the day, the one belief I had that was clarified was that I firmly believe the Iterative approach is better suited for Agile Software Development Projects than Continuous Flow.  This was confirmed by the following three observations:

1)      Iterations assist in minimizing movement, providing focus, and maximizing feedback.

2)      Not all User Stories are independent and interchangeable, planning is required

3)      Goals and Measurement are required for Innovation

Although Continuous Flow has great benefits for processes that are independent, repeatable, and predictable, I firmly believe the problem solving nature of Software Development benefits from the planning, execution, and feedback structures of Iterations.

All from a little game of Perfection. 🙂

How we improved our #Agile Daily Stand up

I’ve been in a lot of different projects with a lot of different stand up meetings, but recently I was at a client site that held daily stand ups for a team of over 20 people and the meetings were still under 10 minutes. Before I get into what made their stand up unique, I’d like to first share my stand up experiences…

My Daily Stand Up experience

Problem #1 – Too long

I’ve been on many teams with that held Daily Stand ups. The size of these teams varied from 2 to 25. But on every single project, we struggled with the Daily Stand ups running long. Everyone usually reported quickly on what they worked on yesterday and what they are planning to work on today. But then when we got to issues portion, a lot of things happened that were hard to control. Some of the things that were hard to control were:

• People used it to complain about all sorts of issues
• People used it to ask a question they had for one other person because it was the first time they saw the person that day
• People used it to discuss non-project related items (Business Development, Marketing, and others)
• People shared far too much detail in these meeting

Sound Familiar?

Problem #2 – No client representation

The second problem I frequently encountered was that there was no client representation in the Daily Stand Up. I was one of the people who had reservations about clients attending as I wanted to have the freedom to discuss all issues without potentially alarming clients. I see now in retrospect that this perspective was a holdover from my Waterfall days and was a mistake. By not having clients at the meeting, we were still encouraging an Us and Them project division. I believe it also allowed for more complaining instead of facilitating the reporting of just the issues that required assistance. I also felt that the client was not aware of all the issues the project was dealing with as they were not at these meetings. I think issues were more of a surprise than they would have been if they had attended these Daily Stand Ups. In fact, I bet they would have helped the developers out by removing troublesome scope if they knew the issues being encountered.

My New Observations

The client I am at now had the following three questions that they asked the team members at the stand up:

1. What did I work on Yesterday?
2. What am I working on Today?
3. What do I need help on?

I loved the phrasing of the third question. In a subtle change of wording, these Daily Stand Ups have been absent of any complaining and insertion of questions that should not be part of a Daily Stand Up. Now the only items being brought up other than yesterday’s and today’s status is what I need help on. I think this is a brilliant rephrasing to ensure focus is on what the meeting is intended to accomplish.

That said, we don’t have client participation in the Daily Stand Ups yet. But this just the start of the project and hopefully we can involve the clients as we proceed…. It is all about getting better…

 

#agile2011 Monday night thought – Does using only #Velocity limit the opportunities for #acceleration?

I just finished reading an excellent Blog entry on transitioning from traditional estimating to Story Point estimating by Ilan Goldstein. You can find the blog post at the following link:

transitioning-from-timebased-to-relative-estimation

The article walks through the estimation process used during the transition there are three excellent points.

1. I loved the idea about being above-board and listing the conversion table between Story Points and the range of hours typically associated with those Story Points. Let’s face it, everyone is doing the mental math and the only thing worse than people doing the calculation, is everyone using a different version of the table in their own head to do the calculation. So let’s all just agree what that conversion table is. Excellent.

2. Taking previous features developed and incorporating the effort they took into the estimation process is wonderful. I have not heard mention often enough about tracking and comparing estimates versus actuals on User Stories so that our estimating get better each Iteration. This process of creating reference User Stories in points by converting the hours they actually took helps to leverage the previous project work to make the estimating of future work as accurate as possible. Brilliant. The additional step to then throw away the hours per feature and use on the Story Points going forward is ideal.

3. The point to then track both the time completed and the time remaining on active User Stories ensures that we are continuing to learn and get better with our estimating as the project proceeds.

I think these three points just add the value of planning poker and makes the entire estimation process the best it can possibly be.

Why do I like these ideas and processes so much and what does that have to do with the title of this Blog?

It has always been a personal belief of mine that setting completion expectations for a project team with only a collective measure (velocity) for the entire iteration is not optimal. Using relative estimating to produce accurate estimates and using velocity to plan for the average progress of a project is fine, but even Mike Cohn stated he does not recommend using Story Points for Sprint Planning.

why-i-dont-use-story-points-for-sprint-planning

Mike Cohn mentions that velocity is not a useful short-term predictor and I agree. I would also add that not only is it not a useful short-term predictor, but also can possibly not set the proper short-term expectations for User Story completion times. When used, Story Points by their nature allow for a separation from day-to-day complexities that can cause inaccurate estimates. When used, Story Points by their nature can also allow for a separation from day-to-day expectations. For example:

• How long should a 1,3,5, or 8 point story take?
• Do we need to wait until the end of an iteration to react to a story that is taking longer than thought?
• Would knowing that a story should take 2 days on average help to alert the developer of potential issues?
• Would knowing that a story is going to take longer than expected allow for the splitting of a story in the middle of an iteration and the ability to deliver more ‘Done’ work in the iteration?

If I am for the most part only reviewing velocity at the end of the iteration and not at some level on each User Story during the iteration, am I limiting my opportunities for acceleration?  (Acceleration being the rate I can change my velocity.)

Thoughts?

#Agile Games in Killarney

I was watching my son and daughter and their cousins playing games on the weekend and it struck me on how children really operate in an Agile way. The kids were playing monopoly and it was fascinating how they used the general rules and then customized the rules if they could get an agreement from every participant. It was something I don’t seem often with adults. We seem to read the rules and then consider then sacred. I even have seen huge arguments when there is a disagreement on the rules that will be followed. Somehow as we get older, we seem to get less brave in how we play games or work.

I have heard some Agile proponents discuss how everyone needed to absolutely follow Agile practices just like how people absolutely needed to create functional specifications for a waterfall project in the past. Blind faith in any process is not Agile.  Agile is understanding the process guidelines and understanding when and how they have been customized to create the most value. Granted that there are some practices that will apply more often like User Stories, Planning Poker, and automated testing. But we do need to be careful in that we don’t fall into the same trap of demanding these practices are always done.

But more fascinating to me was that the kids modified the guidelines in an iterative manner! They played for a while and then based on the success and fairness of the rule, they modified the rules. When my daughter did not have the same amount of properties, they modified the rules. They understood that winning the game was not success, everyone having fun and being involved was. Once again, they only modified the rules when they were able to gain agreement from all players. They played the game in the same manner people suggest Agile project should be done.

So the question is why do adults seem to require strict rules? It seems much of the Scrum methodology was a reaction to create a rigid structure in the Agile space. That methodology found a home as it filled a need for structure. It seems that the lack of rules does make some people uneasy and nervous.

I believe a true team can improvise, innovate, and create because they know risks are taken by the entire team. They also know their team will support those decisions 100%. It does seem to all come down to trust.

Funny. Agile teams have faith and trust in the team, and change the process to fit the client. Non-Agile teams have faith and trust in the process, and change the client to fit the process.