Archive for June, 2011

This one is for Mhano. Book 2 of 11 for the PMI Agile PM certification syllabus - Agile Project Management with Scrum by Ken Schwarber, 2004.

Okay well firstly it is obviously about Scrum and doesn’t cover anything XP or ‘A’gile related. Given that it is getting a bit on in age I thought there would be more that I would disagree on but surprisingly little has changed over time.

If you want to know Scrum it is a good start, but really there isn’t a lot of depth to this book with a majority of the book focused on case studies. Ken admits that that is his focus at the start and he leaves the first chapter and first appendix as the process and general rules of Scrum. He wanted the rest of the book to be more about the ‘feel’ of Scrum but really it reads like a number of notable failure modes or Scrum Master correction tips. Whilst some of this information is useful it really is the tip of the iceberg and there is not enough coverage of other information to recommend this for anything past a novice level of information.

Comparing it to the two day Certified Scrum Master (CSM) course, it is probably the same coverage.

Ken openly discusses in the first chapter that Scrum is an empirical process control, meaning software development is hard and consequently the only process we can rely on is visibility, inspection and adaption and then goes on to explain how Scrum fulfills this. It is a valid value proposition and well explained.

The book then goes through the key Scrum roles and a number of other Scrum terms as you proceed through the case studies. As always my main beef is not directly related to this book, but at Scrum itself. I loathe the term Product Owner. I feel it is a poor reflection of a commercial world outside of small software development houses. Rarely do you have someone who is the Project Sponsor, Business Owner and Business Representative in this one role. Merging all three is confusing and not a reflection of standard governance and delegated levels of authority.

Similarly I hate the term Scrum Master, but I also hate what it has done to jumble up the meaning of Agile Coach. They are different, but similar and I don’t know if it is doing us justice having this role. More importantly I fear that the role of Scrum Master is counter-intuitive to the generation of a self empowered managing team.

Nattering on, I also hate the term ‘Product’, specifically when associated with the backlog. This primarily is because it limits the application of Scrum to anything to do with ‘Products’. You can apply Agile and Scrum through so many things other than software development and so the term product for me just doesn’t sit right. Call it a work backlog and be done with it.

Maybe I slept in the CSM class but I can’t remember the strong enforcement of scrums having to be 30 calendar days. I’ve always just used standard lengths of iterations to what suits the circumstances. 30 days seems a little prescriptive. Burn down charts have also advanced away from what is described in the book with Burn Downs generally representing hours and points being burnt inside of the iteration and the release burn done going upwards against scope.

Similar to my major gripe with the CSM course there is no coverage of the art of generating the backlog in the first place, it magically assumes a fairly burped one out. This is an art. It is not simple and for it never to be covered anywhere is just sad. There is a very small reference to doing this in one day…. yeah. I am dubious of the quality of a one day created backlog for a greenfields project. There is definitely something in Feature Driven Development’s domain modelling that is missing in this picture.

The rules at the back are a little outdated but for the most part have their heart in the right place.

Read Full Post »

Make war not love

I was recently reading a thread on the Agile Alliance group on Linked In where Matthew Weaver was asking for some thoughts about why Waterfall is demeaned by those that follow Agile and Scrum. The thread to me got very interested when Scott Ambler brought some metrics to the argument.

Challenged: A project is considered challenged if a solution was delivered but the team did not fully meet all of the project’s success criteria within acceptable ranges.
Failed: The project team did not deliver a solution.
Ad-hoc: The team does not follow a defined process.

I must admit I was a little shocked by this graph. The variance between methodologies (please note I loosely use the word methodologies) and end results were really not different and a niggle grew in my heart – was Agile really no better than Waterfall? Was the likes of RUP better than Agile, seriously?!? Is the existence of no approach, chaos or chaordism (a sub-orderly version of chaos) really just ten percent less successful?

When you look at results there is only a 15% variation at maximum between all of the methodologies – this is by no means significant. When you take into account that non Agile methodologies are tackling the more challenging project types, is it any wonder that traditional and ad-hoc approaches have a higher failure and challenge rate?

At face value, these metrics are proof that we are fighting an unneccessary battle. These metrics are really suggesting that I should find a new career path tomorrow and stop blogging right now.

… hmmm…

Something is missing, or maybe I’m really more dogmatic then I think.

Let me make a little adjunct and go back to the future. I remember reading in depth the Cutter IT Journal Great Methodologies Debate in 2002 (side note this is a facinating read in retrospect). One article, ‘Agile Versus Traditional: Make Love, Not War!’ by Robert Glass took my fancy. As an ex-Waterfallist seeking mental support I saw this article as thoughtful. Not really for the content that it was but for the concept. Given that Agilists back then were referred to as ‘anarchists’, ‘revolutionists’ or as I heard often ‘cowboys’ an Agile implementation beyond a single team was fraught with great risk. These were the days that PMOs have massive amounts of power and control. These were the days that you had to placate Waterfall to some extent so that your transformation would not be quashed by the mass of old school methodologists. This arcticle was a means to support that. We had to pretend it was love and not war even though deep in our hearts we knew it wasn’t really the truth. People hate change and Agile was without a doubt a big threat on the change-o-meter.

But my Agile brothers and sisters - these days are gone! We don’t have to hide behind the big brother anymore. This is war! And until this strange beast of a methodology that was based upon building construction is purely a myth I will not rest in my war.

I will not take Scott Ambler’s logical, sound metrics and ignore the passion that I know is in my heart! I /spit on these metrics (no really Scott I don’t /hugs).

So where do I think there is something missing in this sound foundation? Well obviously over 170 people lied.

Okay probably not.

Then you might think that the term successful meant it was delivered but useless to the end user. Alas, when you read the questions and survey monkey results you see that actually most of the respondants were really passionate about getting the right result and responding to change.

So why do I feel so strongly about my war chant?

I think there are two key elements missing in the survey.

Number One: Were the respondants really, I mean really, doing the methodology they thought they were? I only say this because all too often I see teams that say they are doing Agile and when you delve into it in some detail you find that they are doing Chaos or Chaordism. What I would have loved to have seen was some form of maturity assessment against practices to see whether what they thought they were doing was really the truth.

Number Two: The big ‘A’. Out of the four methodologies in the survey (yes, yes Ad-hoc isn’t a methodology) only Agile is more than just a set of process steps and practices. ‘A’gile certainly has some underlying practices based upon the model(s) that you choose the implement but in addition Agile gives us core beliefs (manifesto), principles and values. This is what I feel sets it apart from the rest. We all know that emotional intelligence and treating people like assets rather than pieces on a chessboard makes common sense but Agile puts this into the forefront of everything. I truely believe that it is this focus on beliefs, principles, values, the way that it empowers people through servant-leadership, that results in Agile teams feeling more engaged. Engagement and fun are such highly intangible results that make or break people’s day by day enjoyment with respect to where they work. I would have loved to have seen the survey ask this question and where those teams sat against Industry benchmarks of engagement.

It is this engagement, passion, and focus on more than just processes and practices that sets Agile apart, that makes me fight this war so hard.

Viva La Revolution brothers and sisters!

Read Full Post »

Over the last few months I have pondered going for PMI’s Agile PM certification. Unsure of how dedicated to this cause I might be, I decided to at least start reading the eleven books on the syllabus and see how I felt after reading one.

The first one was “The Art of Agile Development” by James Shore and Shame Warden 2008. Unlike most of the other books this is one that I have not read and I wondered whether I would get much out of it other than an increase of my own Agile Data Dictionary (otherwise known as the mysterious wheel of terms that mean the same thing but are subtly different).

Because I am a ‘glass is at 50% capacity’ sort of person let me start off with a positive (yes I know that doesn’t make sense, but I just watched House and eww I’m still trying to mentally get over it). If you are a beginner to agile (note the little a) then this is really a good book to start with. It doesn’t cover everything, but it doesn’t say it tries to either. I would recommend this book.

The book is primarily focussed on XP practices. Now keep in mind that XP is at its heart exactly that – practices. This book takes the position that XP has evolved away from just the technical software development practices and is beginning to broaden its focus, albeit in this book it keeps calling all the other stuff practices too. This is where the big ‘A’ comes in. I like to think of Agile as not just either XP vs Scrum vs Crystal vs Kanban; I think Agile is taking what works out of all of them and applying it appropriately.

This book tries to take some of that ‘A’gile thinking and includes topics such as Energized Work, Trust, Slack, etc. This is definitely a good thing as I always found it odd that XP was so incredibly technical practice focussed, but you need to beware that a lot of the content that is being covered actually exists elsewhere in the land of Agile.

From a negative perspective the Practices by Phase table on page 21 made me want to shut the book straight away. It was there to ease the waterfall people but the association of practices to phases are incredibly wrong and most of the practices exist throughout the life of the project. The practices cross reference on pages 26-27 is equally cringe worthy with Scrum apparently the only other model for agile implementation.

Other notable thoughts as I read through:

  • Data dictionary #1 Energized work = Sustainable Pace
  • Data dictionary #2 Informative workspace = Information Radiators/Big Visual Charts
  • Root cause analysis… surely this is more of a generically known term and not an XP practice.
  • Trust… as a practice? I guess. It is a value to be upheld. Is upholding a value a practice?
  • Data dictionary #3 Sit Together = Co-location. Really the word co-location wasn’t used once?
  • Real Customer Involvement… apparently only at Analysis phase. Please can’t we have real customer involvement throughout?
  • Ubiquitous language… seriously don’t get me started on this one. Who in their right mind uses a term like ‘Ubiquitous’ to describe what should have been ‘Simple’ or ‘Audience specific’. This goes along with the weird term ‘Etude’ used throughout.
  • Data dictionary #4 Demo = Showcase
  • Reporting… as a practice? I can see Burn Up and Down as a practice but a generic heading of Reporting is a bit of a stretch. The help box “Only produce reports that are strictly necessary” should have taken up a whole page and that could have covered it better. Nothing in here about a Car Park Diagram, but then again that’s an FDD practice and this is an XP book guising as an Agile book.
  • Data dictionary #5 Done done = Definition of done. I am probably more familiar with the former than later anyway.
  • 10 minute build… love it! I remember having a problem with this one once so I was really happy to see this.
  • Documentation… again not really a practice and dare I really have to go back to the manifesto on this one. Thankfully iPhones have moved on since 2008 and most of us deal with documentation these days as simple snapshots uploaded onto a central project repository.
  • Release plan… it was nice to see the information on this subject represented how it was. One of my pet peeves in the idea that at the start of a project all the work is going to be scheduled into a detailed, Gantt chart like release plan. This section didn’t do this and really focussed more on the adaptive planning of the work.
  • Data dictionary #6 Planning Game = Estimation and Prioritisation. How I have always hated the term Planning Game. Nothing was mentioned here about MoSCoW or Planning Poker (or anywhere else in the book).
  • Risk Management… apparently only gets done in planning (thought the text later says otherwise).
  • Data dictionary #6 Performance optimization = ensuring you have the means to cover off the performance non functional requirements. Again, not really a practice.
  • Exploratory testing… old school software development stuff, not something that XP should claim fame to (not that the author is notably).
  • Practices by Role table is very poor, ignore it; or at least definately ignore the overloaded ‘Coach’ column.
  • Maturity Assessment pgs 63-66 might be useful /shrug
  • Not a fan of the concept of Step 3 in retrospectives “Mute Mapping” whereby you quietly group like themes together. Why wouldn’t you do it as you are facilitating?
  • Not a fan of only fixing one thing and only one thing in retrospectives. Why have this charade of listing everything that isn’t working and needs changing. Now I am not saying fix everything, but surely more than one thing can be fixed! Maybe this is why people have such a rough time following through on actions? Nah, it’s because actions aren’t written as stories and scheduled into the iteration and hence followed up.
  • Version control… old school software development stuff, not something that XP should claim. I was impressed however that they did talk about branching and advised against it – Yes! I feel vindicated after many years of saying no to branching.
  • Really controversial idea on page 240. Probably my only new concept from the whole book. When at the end of your iteration time box any partially done work should be deleted from the code base. If it is important the story will be carried over, otherwise YAGNI. I like how this would seriously focus the team on finishing work like the time box should be and would help with that little bit of time for slack. Reality will likely kick in and I will never see this idea happen.
  • Not much of a focus on operational/BAU/enhancements using Agile. Page 242 is the only one that mentions anything and even then it talks about Daily Iterations or having Batman come in.
  • Stories have moved on since this book was written. There isn’t much in the book about Features and nothing on Epics. There isn’t anything about the standard format. It does have the standard comment that stories are for only business work which is a school that I don’t agree with. What are you calling the IT stuff that has to be done guys?!? It was nice to see that regression defects can be handled through stories (another vindication).
  • I liked the idea that developers should expand their automated test coverage by spending more time watching how end users use the system.

Well, there you have it. One down, ten to go!

Read Full Post »

One of the first few comments to my partner after I touched down back into Brisbane last night was ‘Gosh I’m buggered. It’s been such a long week!’

He smirked at me and shyly commented ‘Monday was a public holiday. And you still have to work tomorrow.’

Was it really just two days? It felt like a whole week. All those late nights, lots of preparation, stress of going far out of my comfort zone and a hotel room only three floors away from a night club must have really pushed me hard!

I’m hopefully not going to write a long blog about all the ins and outs of the conference. I’ll let Craig do that as I saw the mountain of notes that he took and I’ll later take the lazy path and just link them. So what high level observations do I have:

  1. Lots of people. Apparently over 650+. But as far as passionate people, it very much seemed like a small group. Watching twitter there was some movement but not a lot, maybe 20 or so consistent twitterers (is that a real word?) Now there would have been an element of passion to attend in the first place but there felt like little zeal.
  2. Keynotes. I had seen something similar for Alistair Cockburn’s presentation before, probably on his blog, so there wasn’t much of a surprise there. It was the first time seeing Rob Thomsett and I had heard lots of people rave about it. I felt the raves were justified – his presentation was passionate, energetic and fun, albeit not covering the topic I thought it would. Side note Rob – the website you linked has broken pages *everywhere* in it. Jean Tabaka had some very cute ideas and some interesting links to books and websites. Unfortunately the links quoted weren’t right, but I eventually found some of it at http://www.gogamestorm.com/ and http://innovationgames.com/. I didn’t get to see too much of Martin Fowler as I left a little early to go back home.
  3. Key themes. Its all about teams. Agile isn’t a methodology – its a significant culture upheaval, a revolution.
  4. Best quote: Every time some does a Gantt chart a fairy dies.
  5. Most relieving moment? Finishing my presentation! How mean was it making me be stressed the whole conference leaving it till the end? But seriously, I am so happy I did it and it was a considerable personal stretch. My presentation aims fulfilled - to have the most ‘out there presentation’, only stage jumper, getting through it without passing out. I wanted to be energetic and funny but I also wanted people to be able to take at least one thing out of it. Hopefully some people took away a better understanding that their transformational pattern actually has a name, behaviour and risks associated with it.

Thanks to my Suncorp ‘hood’ for your support on the day!

Read Full Post »

Okay so I don’t get asked this question enough but feel a need to justify it to some extent because I am tremendously passionate about it.

Why am I, an Agile Coach, so fascinated with MMORPGs (Massive Multiplayer Online Role Playing Games)?

At its heart the reason is fairly simple – because behaviour is unconstrained, and unconstrained behaviour makes for some very interesting human nature observations.

For those without much of an understanding of MMORPGs let me digress for a moment and describe them a little. You may have heard of some of them – World of Warcraft, Everquest, Second Life, Eve, Rift, Warhammer, the list does go on a while. Within these games people play on a server; sometimes there are hundreds of servers for the game. On a server can be tens of thousands of people playing. As long as a player is online on that server you can see them in front of you (assuming they are standing in the same virtual section of the virtual world). You can interact with them and others in the virtual world around you. You can also interact with virtual computerised characters inside of the world.

The motive for interaction is to ‘progress’ or ‘advance’ in the world, ie become an expert in what your chosen direction in virtual life is (sounds familiar right?). Once you reach this expert layer you can then tackle hard projects called ‘bosses’.

Now these ‘bosses’ don’t just fall over when you talk to them. Generally you won’t be able to defeat them by yourself. Depending on the conditions that have been setup for the boss you might require four other players or even up to thirty-nine other players to use all of their expert skills against the boss. In a situation of you and another nine or more people working together it is not a simple matter of doing one expert action over and over. In fact, the level of complexity needed to defeat these bosses requires amazing levels of co-ordination that would make an average person unaware of the domain of MMORPGs boggle.

To put it into content, one boss might take a coordinated effort of twenty people thirty hours before he is defeated. This is thirty hours of complete concentration where a single second of failure from one person might result in a total group failure.

It is in this environment that I find MMORPGs fascinating -

  • What incentivizes individuals to spend hour upon hour with people they don’t like to defeat these bosses?
  • How do these teams form where there are no real world boundaries constraining them?
  • How do these teams reach peak performance when there is no body language to read?
  • With absolute anonymity how to people behave differently than they would in the real world?
  • How does a culture form inside MMORPGs?
  • How safe to fail is it when a single error from one person might result in significant disappointment of nineteen other individuals?
  • How does retention and recruitment work when there are no legal constraints on a system?
  • How does virtual corporate purging and takeovers work when there are no legal constraints on a system?
  • How does hierarchy and leadership naturally form and work optimally?
  • Do similar problems of Manager vs Leader exist as in a real world business domain?
  • Does storming, norming, forming, performing fit?
  • How does burnout occur for highly motivated people?

But the most fascinating element is

Are MMORPGs the future of our world and consequently the unconstrained nature of them?

I predict the business world to change much in the next ten to twenty years. I predict a world where white collared workers conduct their activities from home in a virtualised business environment where they can virtually walk up to their team member (who might be physically in a different country) and have a discussion/collaborate on some work together. Each day we are inching closer and closer to this, but this will be a virtual world where you sit in many realities at once and that excites me tremendously.

What we are learning today within Agile I feel will be very important for the virtual world of the future.

This blog entry is dedicated to that vision but is also a nice little wrap up for some posts that I will do in the future about this relationship. Expect the dot points remarked above to be answered in future posts.

Read Full Post »

I had the lovely pleasure tonight to see Jean Tabaka in action at the Brisbane YOW night. Topic in reflection: 12 Agile Adoption Failure Modes.

My interest was immediately peaked when the opening question was “Ask the four or five people around you what are some of the key causes for an Agile Implementation to fail”.

What we were met with was two elements of failure – 1) at a team layer and 2) at an organisation or enterprise layer. An element of distinction between these two was not really made so I am left to assume most of the twelve failure modes are directed at an enterprise layer.

On the first failure mode I felt a little shaky. It was called ‘Checkbook commitment’ and was pitching failure where the Agile Champion is just a Sugar Daddy (my words) –  all money but no heart. I don’t disagree with this as a failure mode but feel it goes much further. To have a Champion in the first place is a good thing. One failure mode would be that one doesn’t exist; another would be that their expectations are unrealistic and they pull the plug too early in the piece to reap the reward, or one that doesn’t stand up for the framework and lets governance bog it down with unnecessary requirements. The failure is in several layers of the Champion not necessarily that they are only a checkbook.

Then failure mode two hit: Your organisation does not support change. My faith was getting weaker with immediate thoughts as to whether this was a cop out statement. What organisation DOES support change? If an organisation was supportive on change then surely Agile Implementation would be a no brainer. This is why cultural change takes an average of seven years and without a doubt Agile is a significant cultural shift for most organisations.

Now in fairness Jean had incredible jet lag and sleep deprivation so maybe the words didn’t come out right. When the closing slide was done I looked at it curiously – failure mode two was renamed to “Your organisation does not support learning” – was the initial slide a typo or the recap was the typo or did I just fail at paying attention probably and mis read it? If the point was supporting learning then maybe I could see that as a failure mode, but this is probably the only point in the whole presentation I wasn’t sold on.

There were further comments that occasionally peaked my interest. There was a reference to ‘insight’ and I felt that this had synergy with Alistair Cockburn’s recent post of reflective improvement frameworks.

Another point was made about servant leadership and this one really made me think hard. If we are trying to achieve a servant leadership environment – is the Scrum Master/Iteration Manager role counter-intuitive to this? Is the role we seek more really an Agile Coach rather than a Master/Manager role. Perhaps just the titles are bad, but all too often I have seen teams not take on collective ownership of the story wall, not take ownership of helping to facilitate retrospectives. I have heard many SM/IMs call the role an almost ‘administration’ role rather than a coaching or mentoring role. Maybe we are doing ourselves a dis-service in the furtherment of Agile by continuing with the Scrum Master/Iteration Manager terms?

On the recent topic of PMOs Jean talked about how a PMO isn’t there to enforce practices. I think I am still in two minds about this. I have re-organised a PMO so that its key function was to ensure that prior to senior executive approval of major projects the right IT people (and by right IT people I mean the real workers) were engaged with the right business people (end users or those that truly knew the business benefits and drive) met together and both agreed that they got just enough detail that they needed to proceed to the next step and that the value was worth the effort. In essence, they were there to ensure that effective collaboration was done. Prior to implementing that change executives would approve projects with no IT input to estimates or timeframes or estimates were changed (read dramatically cut) from what the IT group provided.

Take the presentation as a whole – 12 failure modes. What if a PMO’s function was to ensure that those 12 failure modes did not occur; I wonder if that would be considered worthwhile.

I loved the idea of walking into a retrospective and asking for a confessional (sorry Jean I took this idea a little further). Imagine asking a team that hadn’t performed a retrospective for a while and asking them to start their brainstorm with ‘Hi I’m Renee. It’s been five weeks since my last retrospective”.

I loved the concept of Servant Leadership as “I raise IQ’s for a living”.

I loved the point that performance bonuses are not beneficial to Agile (I’ll probably tackle this on my next blog as it has been mulling around in my head for a few months now and I will be presenting my vision on this when I present next week at Agile Australia).

I can’t recall anything mentioned about Definition of Done on the testing related failure modes but it was on the recap slide (maybe a typo again?).

All in all I got probably 5 takeaways that really made me ponder so A++ to Jean for the presentation, for making me think, and doing it whilst incredibly jet lagged!

Read Full Post »

Dr Evil meets PMOs

A fellow coach, lets call him Dr Evil, was recently describing the fun that he was having on an Agile coaching assignment.

He was tasked to work with a small PMO (thats project… or in this case Program Management Office) among a number of other teams. He put on a cheeky grin like Dr Evil and I saw that he was up to mischief.

Now most coaches when faced with a PMO to work with would begin to educate those involved in the PMO how the PMO evolves to be a supportive function under Agile. Within Agile, a PMO might do a very small portion of governance and might help find resources for certain roles such as a supportive Project Manager, but the concept of a ‘reporting’ function would no longer exist or is simplified to such an extent that only a small number of resources are required.

Dr Evil is not like most coaches. This is a fact that he prides himself on.

Some coaches are supportive, some are direct. Dr Evil likes to think out of the box .

Problem of context: this PMO wanted to have a large degree of say as to how the Project Managers in the Program should be running their work. This behaviour was very anti-Agile, directly reducing the empowerment that the Project Managers should have.

Dr Evil’s solution: Load em up baby!

Dr Evil not only embraced what they were doing, he was actively giving them more… and more… and more. He has been happily tracking their PMO meetings and plotting on a graph the time that the meetings take. This graph is currently on an exponential rise. He hopes that at some point in time (soon) they will break under this ever booming pressure and plead for the Project Managers to make decisions, thus finally giving them the empowerment they should already have.

The current most inane decision sent up to the PMO: desk by desk seating allocation of 80 personnel.

Stay tuned to see how long they take to break, good luck Dr Evil!

Read Full Post »

Ever had that moment whilst Agile Coaching when you just want to /facepalm but you know professionally you can’t.

Here is a list of my more notable moments over a few years (sufficed to say this is not all of those moments):

  • A Standup where the Project Manager stood at the front near the story wall and one by one directed his hand to each team member asking ‘So what did you do yesterday?’
  • Where I had to explain to a CIO of a 400 person IT group what the difference between a Portfolio, Program and Project was (no, he really didn’t know)
  • Where I kicked off an Agile Process Improvement Project that required the IT Leadership Team’s involvement of requirements, setup the initial scoping workshop and was told that it was the first time ever that the Leadership Team had sat in a room together.
  • When I informed a team that we were going to invest in training them and received a reply ‘Why? If we are skilled then we would just get a job elsewhere.’
  • A Project Manager that Gantt charted over 500 stories across six months of work onto a wall and then continued to ask the team on Iteration ‘x’ why they weren’t working on the stories on the Gantt wall.
  • COTS implementations run Agile where Business Process Transition Analysis was not in scope at all. Apparently people figure customisation is better than configuration + process change.

What are your biggest /facepalm moments?

Read Full Post »


Get every new post delivered to your Inbox.

Join 920 other followers