Hypothesis: Is there a way to increase the odds of a successful change by understanding your organization culture from Schneider’s culture model and how the MBTI (temperament and function pairs) of the people involved in the change fit into each of the four culture types.

Here’s how I ran the session:

1. Brief introduction to MBTI so people can become familiar with the model.  I use my type (ISTP/INTP) to describe the model.  For this session we feel function pairs (how people process data and make decisions) are better suited than temperament.  The four function pairs are ST, SF, NT, NF.
2. Exercise to help people figure out their MBTI function pairing.  I assumed most people wouldn’t know their type so 4 statements were given and people decided what statement most closely defined their stance.
3. People split into 4 groups based on their function pairing and created a mission statement and described what a successful ‘agile adoption or transformation’ would look like.
4. Each group de-briefed
5. Each person wrote their function pairing on a sticky note and posted them on the Schneider culture quadrant where they felt most reflected the type of organization they would want to work in.  The culture types were not given, only descriptions of them.
6. Group discussion

Overall the goal of this exercise was to see how MBTI function pairings and temperament related to organizational culture.  The exercises were planned to not introduce bias by giving participants the labels of the function pairs and organizational cultures.

Here’s a picture of the Schneider culture quadrants and each participants function pairing sticky (click to enlarge):

Observations:

1. Crowd bias: given this was an XP Toronto meetup, the group agreed crowd-bias came into effect where most skewed towards Cultivation and the ‘possibility’ axis.
2. During the exercises, each function pairing group seemed to come up with a mission statement that aligned with the values of their function pairing.  For example, the NF group’s statement was “am someone who is guided by my passions and beliefs, has a sixth sense about people, and works to ensure harmony in the workplace”  Their mission statement was “In our organization we work to common goals, make the best possible work environment to maximize our people’s potential“
3. The “NT” group didn’t finish composing their mission statement.  The NT pairing is all about ideas and it’s common for lots of idea generation without a firm decision compared to other groups.
4. The “ST” group had the least number of ideas and they were more firm and concrete.   The ST group also finished all the exercises much quicker.
5. The “ST” group debated about having highly specialized people vs more general specialists.

Virginia Satir Change Model:

We also mapped temperaments to the Virginia Satir change model and discussed how different temperaments are affected differently by change.  SJ (sensing/judging) want to remain in the status quo to protect the group.  NT’s (Intuitive/Thinking) tend to want to progress through the change as fast as possible and react with more ideas to changes that have yielded no results yet.  SP’s (Sensing/Perceiving) want to move through the change as fast as possible to find the next problem to solve.  NF’s (Intuitive/Feeling) want to make sure everybody is ok while the change is happening.

Combining the Schneider Culture model, MBTI and Virginia Satir change model can be an effective way to create awareness around an organization and it’s people to increase the odds of a successful change.  I’ve often heard the Agile community say things like “change is hard”, “culture is important” and “one-size-agile doesn’t fit all”.  I think the intersection of the these models is the “why” behind those statements.

I want to offer this workshop again to collect more data, if you are interested, please contact me!

1. the data may have been entered correctly
2. the data input screen may have made the data entry person believe they entered it correctly  (perhaps there was validation that wouldn’t allow the operator to enter “25.00″ so they entered “25″ and there was some error that transposed the zeros incorrectly
3. maybe the person entered “2500″ and forgot the “.” and there wasn’t a check to say “are you sure you want to add a “$2500 fee”?
4. maybe once the item was scanned, the fee being displayed was being rendered incorrectly
5. maybe the person entering the data was working on 12 things at the same time and simply messed up
6. Maybe the data was added with a bulk script and there was no test to validate it
7. maybe there wasn’t a test in place that could have caught the error before it was deployed
8. maybe there wasn’t a conversation that a clearly out-of-boundary error wasn’t a big enough deal to worry about (I’ve never heard of a $2500 fee for electronics before!)
9. maybe it was the data entry person’s last day and he really wanted to mess up this company

There could be many more possibilities, my point is there is much more going on than “the idiot who entered the fee incorrectly”.  There could be numerous causes and a possibility for a large loss of sales revenue.

It gets worse.  The people in the store didn’t add that fee, it was added automatically when they scanned this item.  The people in the store cannot correct the environmental fee price.  The people in the store called head office and “the guy was on lunch”, which is where we would have liked to have been.

So in my brain I see software doing something the user didn’t intend for it to do (add a fee), wouldn’t allow the operator to correct it and gave the operator no course of action to correct the problem with a customer who was prepared to plunk down a few hundred dollars right there.    Were other stores affected? This was a chain store  so I will assume their POS devices are accessing a centralized system.  How many items do each of these stores sell that have this fee and how many customers would have been turned away until the problem was fixed?

And what really happened anyway?  Was it a data input error? Was it a system problem?  Who knows and it’s un-likely we’ll find out.  All we know is we need to go back and pick up the item in a pain-in-the-ass-area of the city to get to and we wasted our lunch.

I’m probably nuts but I know how I would handle this problem, what would you do?

Some of the symptoms included not finishing the sprint work, disagreements about what done meant to the developers, testers and business people, struggling to finish regression, missed deadlines and releases.  It’s always tough to gather enough context in a short amount of time to offer some advice.  I could see the main challenge was getting the team to buy into a shared goal and removing the silos.   Having said that, these guys seemed quite collaborative, I think they were simply having problems adjusting to Agile given they’ve only been trying it for a couple of months.   I think they’re on the right track and seem committed to improving which is just great.  Anytime people want to give up their own time to learn is a good thing in my books.

As we talked about ideas about how to find balance I suggested one way to help manage these symptoms is to pull less work.  Of course every action has some impact and I mentioned that this can create idle time, especially in cases where “the development work” is low effort but the “testing work” is high.  You could have developers idle! Nooooo!  I could see an adverse reaction to that suggestion so I made a joke about making sure “resources” are 100% utilized!  The reality is, people need slack, especially to learn a new process and move forward.

I asked the product owner flatly that if they are missing releases now.  He said yes.  I asked if they have quality problems as a result of in-sufficient testing.  He said yes.  I then asked what’s the harm of slowing down?  Your missing releases with lower-than-desired quality now.  You’re only fooling yourself if you think slowing down is going to cause problems because you already have those problems now.

I could feel a bit of shock from a couple of people in the room after I said that.

The point is, when you are looking for a coach or consultant, they’re not there to be your friend.  They are there to help you figure out how to solve, manage or cope with your problems and you are not going to like some of the answers you get.  A good coach is going to tell you either the brutal or kind truth and the best you can do is establish personal safety by having an agreement and shared understanding about what is expected from the coach from your perspective and the same from the coaches perspective.  Once you can get that agreement in place what unfolds can happen in the name of progress.

“The #agile community is too closed. We are doing intellectual incest, and congratulating ourselves for it.” ~@mhsutton #ACCUS“

I can understand and appreciate the comment, I’ve posted many times about how I think the Agile community is disconnected from the reality that organizations are going through.  Having said that, I’d have to disagree with the statement that the Agile community is too closed.

There are numerous conferences across the world, user groups, study groups, forums, open spaces and local events that are easily accessible to just about anybody who’s willing to learn.  The key is that people need to be willing to learn.  I’m happy that 2 people I worked with when I was consultanting are speaking at the Toronto Agile Tour this year and the reason they are is because they were exposed to what the Agile community offers and they jumped at the chance to get more involved.  They’re dedicated to improving their skills and they have a desire to learn more.

I think the Agile community is awesome.   For starters, look at all the free advice through blogs and forums people in the Agile community give.  Look at the free whitepapers and experience reports the Agile community dishes out.  Look at how people in the Agile community give their time to the community through open spaces and other local events.  Most importantly, the people I know and have tremendous respect for are not content with being mediocre and being around that mindset is infectious.  We challenge each other, we question each other’s statements, we challenge the status quo in the name of building better software and improving the quality of life by living the Agile values and principles.

While I can understand the statement about the Agile community being too closed, there is responsibility on the shoulders of those who are not involved in the community.  Events and information are so easily accessible, there’s no excuse for anyone who wants to learn how to build better software to get off their ass and go learn.  Mediocrity is a choice, people and teams have more control over improving themselves more than they think they do and those who are content with where they are will likely never really get what the Agile community has to offer.  I pay for my own training, I give my time freely to help people new to the community, I am never satisfied with the status quo and my mind is always open to learning something new everyday.

The Agile community is about what’s possible.  The Agile community is constantly innovating better practices for building better software and making work more enjoyable.  People I know in the Agile community are using their knowledge to improve education for kids or improving government or making work fun by using games to teach techniques for building better software.

The Agile community taught me how to value my own skills, how to appreciate myself for the skills and experience I offer and most importantly, the Agile community taught me that no matter how much I know, there is a whole world of knowledge I’ve only scratched the surface on.  I am deeply grateful towards the people I’ve worked with and learned from over the years and I feel honoured that many of these people who are thought leaders in the industry consider me their peer.

The Agile community is too closed?  In my opinion it’s not.  Everyone has a choice to improve them-self, with so many easily accessible Agile events and materials to learn from there’s unlimited avenues to explore.

Thank you Agile community.

There’s usually a development team, test team, release team, product team, implementation/support team etc and these groups are usually silo’d each with their own hierarchy.   Perhaps fodder for another post, I find that these structures and hierarchy often mimic manufacturing.  Put some requirements in one end and out pops the toaster from the other end.

You can avoid scaling problems, or at least minimize them, by understanding how the work evolves as you grow.

Many years ago I worked for a 3-person start-up company.  Life was simple then.  Worked flowed from the customer to us, we did the work and then we showed the customer.

One customer was closely followed by the addition of 3 other customers and the organization grew.  As a result, the work system changed even though the actual work didn’t:

Communication and work was flowing in an ad hoc fashion throughout the organization.  The first customer was fine as they were dealing with one of the founders who wrote the platform so we locked him in a room and called him Frankenstein code ninja guy.

There wasn’t much thought into creating this structure, as it was a start-up, people just naturally silo’d themselves and did what we could to handle the work.   In a nutshell, customers and prospects would generally contact whoever they knew at the company to get work done.  The result was a great deal of chaos, no real planning or strategy and instead more of a ‘lord of the flies’ culture emerged.

One box missing from the diagram is the Operations group.  They (well, he…it was one guy) were the gatekeeper and eventually took hold over all production deployments so there was one more hand-off in the chain.

By this time the company had about 20 employees and then we were acquired.  Things got interesting then.

Follow the orange lines, if you can, needless to say communication and flow of work became very complicated.  As an example, the yellow line represents a common type of work request and each number represents a step in the process.  This example is a customer  requesting a new implementation of the product.  I am speaking abstractly about the product because the product doesn’t matter.    By this time the company had about 250 people working for them.

You’ll notice legacy ninja guy is still all by himself.  Nobody wanted to touch that codebase.

(1) The customer would contact the account team with the request.

(2) The account team would engage professional services for feasibility and timelines.  There was usually some back and forth between these groups and the customer.

(3) The professional services team would engage content creation and the development team if there were any product customizations required.

(4) The content team would produce the content and hand it over to QA while the professional services team was finishing the implementation and loading the content.

(5) QA would then test the implementation and there was usually back and forth between QA, professional services, content and the account team and customer.

(6) Professional services would hand the finished solution off to the account team.

(7) The Account team would hand over the solution to the customer.

(8) The Customer’s new implementation gets passed into the Support process.

The problems we experienced were similar problems I see with clients:

• time and effort wasted during hand-offs
• fighting between silos (professional services and the account team wants the implementation out the door but those pesky testers are getting in the way)
• scheduling confusion
• overloaded professional services team (too much work flowing through them, support interruptions, some technical pre-sales work)
• senior management fighting about priorities and direction as the react to how the work is getting done

I was leading the Professional services team and we were using Kanban (although we didn’t know that was the word at the time) to flow the work through our system.  Actually to be more accurate, and to provide a nice buzzword, we were using Scrumban since we did stand-ups and retrospectives but weren’t working in sprints.  In fairness we did what made sense and none of us knew what Agile was at the time so we’d throw out stuff that didn’t work and do more of the stuff that was working.

We provided lead times and cycle times to the account team and our biggest gripe was being the whipping-boy group.  Any between-the-org-chart work by default came to me since I was one of the original 3 people.

Oddly enough our WORK was EXACTLY the same as it was before however our system had grown so utterly complex it was difficult to get that work done.  Hindsight is 20/20 and here’s an example of designing a scalable work system to support the work being done:

Since the work didn’t change, the system didn’t need to change as drastically as it did and we could have created multiple cross-functional teams to handle the work.  The only difference between the first stage and this one is the extra hop when interfacing with product development which seems like it’d be a good idea so we don’t end up with legacy ninja boys all over the place.

Would this have worked?  Maybe.  The point is with all the hub-bub around scaling and if Agile’s good enough to scale, what is getting lost in the shuffle is understanding the actual work that is being done.  Organizational leaders fall into the trap of building structures they are familiar with, what they did at their last job or what is thought to be the typical way to scale (read: functional departments and hierarchy).

If that worked they wouldn’t need ‘Agile’ to get the work done.  If you’re considering adopting Agile, take the time to understand the type of work you’re doing and build a system to support that work.  That’s like diet Agile.  All the benefits and none of the wasted calories associated with wondering whether or not you’re Agile enough.

Whenever lab time rolled around he couldn’t put together a basic circuit to save his life.  His strength was his strong memory, theory knowledge, and the ability to speak abstractly enough about the topics we studied so his reward was good grades.

But he couldn’t DO the work.

Mark Zuckerberg mentioned in a recent interview (http://gigaom.com/2010/09/10/a-time-capsule-of-mark-zuckerberg-from-2005/ ) that some of his best hires had no programming experience and one of the employees who wrote the Facebook photos application was an electrical engineer, not a software engineer.

I’m not going to go into great detail about the good and bad of the various types of Agile certification, all I’m proposing is that we in the Agile community figure out a better way to build skill within the community and a better way to provide organizations with the right skills they need to be successful.

Look to the Skilled Trades Community

In order to become a Certified Electrician (in Ontario anyway) you need to complete 9000 hours in an apprenticeship program which is a mix of on-the-job (80 – 90%) training and in-class (10 – 20%) training.   Of course there are a long list of regulations, courses and governing bodies that make becoming a Certified Electrician quite complicated.  The point is you need to demonstrate hands-on experience and pass a test all the while getting time to practice with skilled peers.

My Goal for this ‘Certification’ Program

1. to help organizations find the right person or people to help them transition to Agile (process coach?  technical coach? scrum master? management consultant? – typically organizations need many different people with different skills)
2. to help people in the Agile community improve their skills and knowledge through peer feedback and evaluation
3. to help engaged coaches find people with specialized skills to help them with clients (After all, there are many fantastic and knowledgable people you probably have never heard of and aren’t considered ‘thought-leaders’)

A Proposed Solution

I’m proposing a social Agile community that is peer-driven and comprised of a set of community-nominated subject matter experts and thought leaders that can help elevate the levels of standards around Agile practices.

Think of something like Linked In profiles specific to Agile practices and experience along with an apprenticeship program.  I’m not sure exactly how to solve the certification problem without making a new certification so I’m thinking of a level system whereas people move up levels similar to role-playing characters.  Plus that would be kind of neat to make it fun wouldn’t it?

I see a level system with multiple tracks as there is a wide variety of skills needed to help an organization be successful with Agile.  That ranges from people skills, management skills, Agile process skills, hands-on technical skills in programming and testing and more.  Each track would have multiple levels.  Maybe this is getting complicated, I figured I’d throw it out there to start a positive discussion instead of just bitching about what’s wrong with today’s certification.

Possible Tracks:

• Organizational Coach: works on multiple levels within the org (think CSC)
• Team and Process Coach: works with teams, specializes in processes (think CSP, CSM, PSM)
• Software Craftsman: kick ass programmer and tester for the lack of a better phrase (think CSD)
• Product Owner: think CSPO
• Agile Trainer: facilitator, workshops, training, games (think CST, Innovation Games master etc)

This is just a rough idea, some people may specialize in one track, others might just be freaking awesome and reach all levels in all tracks.  Again, this proposed solution is to help the community build skill and help organizations find the right person (people) to help.   Perhaps the Perfection Game is played during each Level to give candidates skills to work on to move up to the next level.  Think of it as employee performance reviews except these would actually be useful and motivating.

Level 1:

- face to face committee panel interview:   This would test candidates knowledge of Agile processes, theoretical situations and some type of simulation to allow candidates to demonstrate working knowledge.  It assumes little or no hands on experience.

Basically a panel interview replaces the multiple choice exams used today.  After all, some of the people I went to CSM class with clearly were there to get the acronym and didn’t demonstrate passion or interest in what they learned and they received the same credentials as me.

Level 2:

- Face to face committee panel interview: deeper level of knowledge explored compared to Level 1

- Involved in local Agile community: goes to conferences, contributes to online discussions, demonstrates a deeper level of passion about their craft

Level 3: (peer evaluated through paired engagement, published articles or books, conference speaker etc)

- Apprenticeship: N hours of paired or shadowed engagements

- Author/Speaker: published books or articles showing commitment to community

Level 4:

- Apprenticeship: finished N hours of apprenticeship

- Nominated as thought-leader and/or subject matter expert

These are just rough ideas, some other thoughts:

• Thought leaders are nominated by the community, some will have global influence, others may have local influence.  For example, to do the apprenticeship in Toronto, there would be local, nominated people available so candidates don’t need to travel
• Peer-driven, community member profiles:
  • Shows candidates ‘Level’
  • Courses you attended (CSM, PSM, NLP, ICF etc) – basically any course or education that is relevant to your track.
  • Recommendations: peer recommendations like Linked In however you can only be recommended if you have paired with another peer at a higher level (not sure about this, thinking of some way to make a recommendation meaningful)
  • Experience: think resume or actual Linked In profile
  • What makes candidate perfect: areas to improve instead of a ‘strength and weakness’ idea.

Why I Think Something Like This May Work

• There is more motivation for me personally to have the respect of my peers, getting feedback through interviews and apprenticeships instead of faceless tests helps me improve which helps the community.  There’s a natural incentive for me to move up levels and it’s more difficult to game the system than simply pass a bunch of tests and get a bunch of acronyms after my name.
• Demonstrates to people outside the Agile community we are serious about improving our craft and help them understand that motivation, determination and passion are more important than formal education alone.
• Builds community and gets people collaborating for the good of our professions
• Weeds out unscrupulous people

Challenges and Questions

• over time politics and other bullshit might get in the way, after all, we’re human
• lack of financial model.  who’d pay for the apprenticeship? who’d pay for though-leaders to take time away from paid work to sit on a panel?  should there be yearly union dues or membership fees or some type of subsidy to help folks who can’t pay out of their own pocket to participate?
• risky for candidates – if your peers think you suck it could be quite humiliating plus it can take away your livelyhood.  Personally, I’m willing to risk it to put pride back into my craft.
• risky for thought-leaders – when I took my CSM the instructor gave final say on whether or not you earned it.  Will there be enough respect to hold people back if they aren’t ready or don’t have the skill?
• is this group of ideas just too fluffy to resonate with our industry?  What do they really want?

This is far from perfect and far from a well thought-out solution, all I know is after I took my CSM I had knowledge and that was about it.  After I worked as a full-time employee as the ‘Scrum guy’ I knew way more in practice.  After I felt like I failed miserably at my first independent gig, I knew way more.  After I started participating in coaching circles, going to conferences and pairing with other coaches I feel that’s where the learning really started and now I have broader skill-sets that I feel really can help me be more effective.

My hope is that this post sparks ideas with people in the community so we can collectively figure out how to move forward for the good of ourselves and our craft.

What do you think?

Why is there a difference between setting goals in an Agile way vs….um, well, just setting goals.   Are today’s leaders so completely out of touch that they need an ‘Agile way’ to set goals?  What’s next?  The Agile way to get to your car in the parking lot?  The Agile way to keep the fridge stocked?

I recently was talking to a former colleague, who is also the CEO, about how their Rockefeller Habits process was going.  For those who know me, I toot the Rockefeller Habits quite a bit.  It was what Business Agility was before all the hoopla…anyway, long story short I wanted him to talk to another client of mine about their experience implementing the framework.

His response was quite profound.

“We don’t really follow the framework anymore, it’s just how we work now.”

Brilliant.  Simply brilliant.  Strong leaders don’t need “Agile”, they clearly have a deep understanding of their domain and current state and know how to make decisions based on that data.

Perhaps in a less brilliant statement, I remember talking to another client where a manager had said “I don’t know if it’s the Agile way to do it but it seems to work for us.”  Isn’t that just common sense?  If something works, do more of it.

I suppose the more we can figure out how to put “Agile” in front of stuff, the better it is for marketing (hence my agilecoach domain!) but man, sometimes it just really bugs me that folks need to call something “Agile” to validate that what they are doing is the right thing.

By the way, here’s the link to the article, it is very well written, I enjoyed it very much!  Rant over.

What happens after the honeymoon is over?  Going from blank walls and cubes to a lots of stuff on the walls and a nice wide open space and should have made a difference by now shouldn’t it have?

There’s a lot of noise on Linked In, Google Groups and twitter (to name a few) that all seem to try and find fault in a person, team, organization or practice because the results aren’t matching the rhetoric.    So we’ve been at this Agile thing for a while, we found a shitload of problems, came up with a plan to fix them, didn’t see results right away because we chose to not prioritize actually fixing these problems, blamed the methodology and decided to go back to the old way of just ignoring said problems.  Voila!

I remember that fantastic exciting and new feeling when I first met my wife some 15 years ago.  It was fun.  New.  Exciting.  Fast forward to marriage and kids and after the honeymoon was over life got hard and complex.  It takes work to manage our house and family.  Real work.  Any problems we have are our problems and if we chose to ignore them, we suffer the consequences.

According to these stats, 1 out of 2 marriages in the US and Canada fail.  Why is that and what does it have to do with Agile?  Plenty.  When stuff gets hard, we as humans give up.   This Business Week article talks about 5 reasons why we tend to give up on our goals.

• Ownership: thinking “I’ll give this a try and see what happens” instead of thinking “this will work only if I make it work”
• Time: holy cow, I didn’t think it’d take this long, is it worth it?
• Difficulty: This is waaaaay harder than I thought!
• Distraction: Sorry, can’t work on my goal, have a bunch of other stuff to do.
• Maintenance: ah, good enough….I don’t have to keep working at it do I?

Adopting Agile is no different than any change in a company.  It’s a change.  A big change.  A really big change and change is hard.  All the mental models, coaching models, change models, methodologies and such are fine and dandy but sometimes you just need good old fashioned gumption.

Sometimes it’s time to nut-up or shut up.

Peter is confused and grossly mis-informed about what Agile practices are so I crafted a response (as brief as a could given how much bad information in his article) to his statement: “Agile software development methodology sucks ass. Big time. Totally. 100%. Entirely. Gosh, I hope I‘ve stated that clearly enough.”

Come along for the ride won’t you please?

Most of the rants in the article (here’s the full article) appear to be about the execution mechanics of Scrum and Scrum doesn’t really speak to the full life-cycle of a project or visioning.  Scrum is about execution which isn’t to say planning, chartering and product discovery aren’t equally important.

He starts out with the “stupidity of its (Agile’s) three most important tenants:”

A maniacal emphasis on just getting something working as opposed to thinking something through,designing how it should work, and getting something working correctly.

This is often the thinking of novice Scrum folks.  People tend to inaccurately think that ‘potentially shippable software‘ means just build some shit and see what happens.  Not the case.  The sprint goal is based on getting a functional piece of software done and it doesn’t imply there is no upfront planning or design.  Scrum says do enough that makes sense to get started sooner since each project has it’s own unique attributes.  Think incremental delivery based on a product goal or vision, not just getting something to work.

Scrum doesn’t specifically talk about project charting or product discovery since it’s focused on what happens in the sprint.  The Agile community in general, however, understands the importance of this.  Have a look at Jeff Patton’s stuff.  He knows, ahem, a little bit about Scrum and how to use Agile to build kick-ass products.

Requiring detailed estimates of how long it’s going to take to implement some piece of functionality.

Scrum actually de-emphasizes detailed estimates and favours sizing and measurement instead.  That means use story points to relatively size the stories since an estimate is just a guess.  It’s best to spend less effort on sizing since we all suck at it anyway.

Us crazy Agile people understand software is complex and it’s an art as opposed to a science.  Scrum uses real data and real progress to figure out how long the project will take, just ask Mike Cohn.

An insane reliance on – and limitation to implementing features for – user stories (AKA scenarios), which yield fragmented feature sets as opposed to designing for well -reasoned comprehensive functionality.

This is often a result of mis-using stories for what they were designed to do.  Depending on the nature of the product or project, ‘shooting a tracer bullet’ means doing the simplest thing that can possibly work.  In the case of building a search engine, for example, the simplest thing that could possibly work is having a basic text search in Sprint 1 followed up by fancy stuff later on.  This helps reduce risk by making sure you can work within your technology stack and after Sprint 1 you have tests that will make sure as you add more functionality you don’t break existing functionality.

Think 80/20 rule.  No need to over analyze or over  engineer something when most of the functionality isn’t going to be used.

Planning Poker is for mentally defective 6 year olds

Peter says planning poker is great if you like “being treated like a mentally defective 6 year old“.  This is precluded with:

“And, that brings me to the second thing that makes Agile suck so badly: The whole ‘estimation’ process. Every time somebody insists that I estimate how long it‘s going to take me to implement some particular functionality, and in Agile it‘s not uncommon to have to do these estimates with great precision, I realize I am dealing with an idiot. Worse, I realize that I am being asked to lie. And I don‘t like lying. Well, at least not to most people and not usually very much.”

Again, Agile focuses less on estimates and more on sizing and measurement.  Size the stories, start sprinting and use your velocity to see how it’s going.  Story points imply less precision by their very nature since they’re based on effort, not time.  Effort drives your duration.

In a nutshell, size the stories, take a bunch of them to start working on, see how much you got done (your velocity) and use that real data to estimate your release.  This process of course would have been precluded with some product discovery (also sometimes called ‘sprint 0′) or some initial modelling.

Next on Peter’s hit list are user stories:

“And that leads me to the final Agile precept that fries my potato: User Stories. Every time I hear somebody say I’ve entered that as a user story I want to puke. Why? User stories are just that: Stories. They’re data. They’re not wisdom from the ages. And, the way I see them used in most cases, they’re not even necessarily fully representative of what the majority of users want or need to do. When your development process is focused entirely on implementing functionality based on a handful of user stories, you more often than not end up with a random, inconsistent, poorly integrated, mess.”

The problem here seems to be his experience of not using Stories correctly.  Stories are meant to convey a users’ intent within a context.   This context is captured in things like themes and story maps which help teams understand the full context of the software.

If you aren’t using stories to satisfy your users, you’re probably not involving the users in their creation and you’re probably not getting feedback soon enough from your users when you’ve created a prototype of the software. Agile’s #1 principle is to ‘satisfy the customer with early and continuous delivery of valuable software.’

I realize I could go on for a few more pages about how much is completely wrong with Peter’s impressions of Agile.  Of course based on his negative experience, I can’t say I blame him.  After all, my dad still won’t buy Ford products since our 1985 and a half Mercury Lynx.

Getting burned by that lemon ruined his whole experience with Ford.

“You code to these particular stories. No, you don‘t get a chance to think through the overall experience for any user. This is Agile software development. You don‘t get to think. You‘re not allowed to design. You‘re allowed to get some code working? so you can try things out. And that code just needs to meet the user stories, and pass the tests that were so lovingly crafted and stored with those stories.   Anything else? Well, that‘s for next sprint.

So, in Agile what you get are ridiculously incomplete requirements, driving a development process that emphasizes sloppy implementation over design, that‘s tracked using a long list of bogus and irrelevant milestones. The only thing that‘s left to wonder about is why everybody doesn‘t think Agile development sucks ass.”

All Agile practices are empirical and focus on the value of a whole team.  That means a cross-functional team of business folks, programmer and testers.  The customer/stakeholder sets the vision, the team executes.  Scrum, as a methodology, doesn’t talk about the vision part, it focuses on execution.  Executing without context is just dumb no matter what methodology you’re using.

Great design in implied in XP.  Simple design, test-driven development and incremental delivery get you to good design.  It doesn’t happen magically, it takes hard work and sometimes teams need to do some upfront modelling or planning.

Peter, we in the Agile community have worked with you before.  I’ve coached many teams with “Peters” on them and what usually happens is “oh, so THAT’S why it didn’t work for us” syndrome.   I can relate based on why I got into Agile in the first place.  Many years back I was told “you don’t understand Agile” because I asked the team to roughly let me know how much I should charge the client to build what they were asking for.

They answered with thoughts similar to your rants.  You just start building stuff and see what happens.  I decided that was dumb so I got trained, started going to conferences and started talking to other weird and crazy Agile people.  Books helped too.

Now I don’t blame the methodology.  Agile doesn’t fail.  People fail when they fail to understand the tool or methodology they are using and it’s too bad you’re experiences have led to to this great epiphany that Agile sucks.

Maybe one day you’ll get a chance to experience an Agile project done right and maybe one day I’ll convince my dad that Ford builds way better cars now than they did 25 years ago.

I was on vacation last week and was working on a blog post when my 5 year old barged into my office asking me to play dominos with him.  I figured I needed about 10 minutes to finish up the post so I asked him to go look at his clock and tell me what time it was.  He rushed out, came back and said, “daddy, it’s 9.25” so I said, “I will play dominos with you in 10 minutes.”

Expectation set.

At 9.35 he comes back in, grabs my arm and says “ok, its 9.35, lets go play dominos!”

“Hang on dude, I need a few more minutes…”

“NOOOOOO he says! I want to play dominos!”

Trust broken.

The great thing about kids is how they live in the now.  I set the expectation that I would play with him in 10 minutes and I broke that commitment.

So what happened?

Bad estimate finishing my post I suppose.  Maybe I gave an estimate based on what I thought was a realistic time frame for a 5 year old to wait regardless of the effort left on the task.  As a result that time-crunch probably led to lack of focus and it all went downhill from there.

Bottom line is I set an expectation, I broke the commitment and the consequence was the dreaded “5-year old melt-down.”

There’s a lesson here, well, a few actually.

1) Trust: When a team sets an expectation with their Sprint commitment they’ve largely said “trust us, we’ll get this stuff done in 2 weeks”  If teams get into a habit of setting expectations and not delivering, that trust will be broken and that has consequences that are much more serious than “oh well, we’ll do better next time“.  The product owner, stakeholders/customer or whoever, won’t believe the team when they estimate stories or when they make Sprint commitments.

Without trust you’ll end up piling more process on top of already existing dysfunctional process to account for the lack of trust.  Sometimes we like to call these “gates” and mask our distrust as “accountability or responsibility”

2) Team Responsibility: When a team sets an expectation, they are responsible for living up to that expectation.  If the team misses the commitment they should be pissed off they missed it.  Of course, when they nail it, it feels good.  It feels good to finish something and present the work to others in the organization.

Without team responsibility you’re just breaking work into 2 week chucks and not behaving any differently.

3)  Personal Satisfaction: Personal satisfaction is a great motivator.  Harvard Business Review posted an article on what really motivates people and progress was the number one factor.   Setting an expectation in the Sprint Planning session and showing the result at the Sprint Demo shows progress which is a great way for team members to feel a sense of personal satisfaction.  This is more important than managing by fear (the STICK approach) or managing with carrots (the REWARD approach).

These 3 factors are closely related.

Lack of personal satisfaction can lead to lack of team responsibility.  Lack of team responsibility can lead to commitments being missed which will lead to a lack of trust between the team and the organization/customer/stakeholder.

The difference between my story of breaking my commitment with my 5 year old and a team breaking their commitment is that I can re-gain that trust easily by saying I’m sorry and by taking him out for some ice-cream.

Chances are a team only has so many ‘get out of jail free’ cards and a pattern of missing commitments isn’t only going to kill your Agile initiative, it’s going to do damage to your business.