Courses Services AgilePM™ Essentials Scrum Master Product Owner PMI-ACP DSDM Scrum Agile Compass Agile Matrix Blog About e-mail me
Agile Projects Agile Project Management at QUTAgile Inception Deck

During the second semester in 2014 we, a group of seven Agile practitioners, delivered the new Agile Project Management unit to 150+ undergraduate students at QUT in Brisbane, Australia.

The goal was clear: to have students learn, feel and eventually see what Agile Project Management is. The content covered the elegant simplicity of Scrum, the needed project rigor from AgilePM (project management perspective on DSDM) and the combination of these frameworks to get the best of both worlds. The unit was delivered as one hour lectures followed by two hours of highly-interactive workshops.

Part of the unit was an assignment where small, self-organising teams of students developed an Agile Inception Deck using a product of their own liking. Over a period of several week students applied what they had learned during the unit and go through the "10 questions and exercises you'd crazy not to ask before starting your project". In the true spirit of Agile, special marks were awarded for creativity, collaboration and continuous improvement. The latter was assessed by tracking the way how teams were seeking feedback from the tutor as their Product Owner.

The delivery format of this unit was an exploration into a complex world using our Agile values, principles and practices to survive. We basically started with a set of high-level themes on our Product Backlog, were instructed to deliver within 13 weeks and let the detailed Agile topics unfold in lectures and workshops while ensuring we delivered best value to our students. Using Empirical Process Control we remained on track and had an amazing journey with our students.

The lesson learned was that only teams can make this happen so thank you to my fellow explorers: Andrew, Mark, Maxime, Melody, Robert and Todd.

Maverick MaverickBook Review: Maverick by Ricardo Semler

In the IT industry we are experiencing a transition towards Agile during the last decade. As CEO Semler has used the Agile philosophy with great success within his companies by delivering continuous customer value, empowering teams and using empirical process control. The surprising fact is that it all happened 30-40 years ago in the manufacturing industry in one of the most unstable market places of the world: Brasil.

The greatness of Semler as a Maverick is that he successfully took Agile as a CEO to the next (enterprise) level with the following enlightening practices:
  • Divide and prosper - split up/off business units if they become too big given that economy of scales is one of the most overrated business strategies;
  • Sharing the wealth - let employees determine their salary and share (part of) the profits. Interesting is that employees only wanted a fair salary and always choose an evenly split of profit;
  • Rounding the organisational hierarchy - the smallest circle with Counsellors is enclosed by a bigger circle of Partners which is enclosed by the biggest circle with all other employees as Associates (with some Associates acting as Coordinators). Movement in these circles was easy. The final movement for Semler was to make himself redundant because who needs a CEO?
This book is just awesome value and according to me a must-read for any manager who wants to make the world (sorry, company) a better place.

Rent a Team Rent a Team: Win-Win SituationsFor Rent
In my previous blog I looked into Agile Contracts. Overall agility in contracts is achieved by flexing scope, fixing time/cost and creating a win-win situation for the parties. However most Agile contracts still baseline some (kind of) project/product scope.

But why not think outside of the box and completely remove any reference to scope?

Instead focus on what really matters in contract negotiations: rent a hyper-productive Agile team!

This implies during contract negotiation we should value:
  • Hiring a capability or service OVER purchasing a product;
  • Hiring one or more self-organising, cross-functional and co-located teams OVER hiring individuals;
  • Ending a contract by the customer when appropriate with vendor compensation (similar when cancelling a rental property) OVER finding a win-win situation upfront in regards to possibly delivered scope.
Do you think this makes sense?

Agile Contracts Money for Nothing and your Change for FreeAgile Contracts 

The reality in a complex environment delivering complex products is that when you fix project scope in a contract your probability of success significantly decreases. Better is to design a win-win Agile contract deal between customer and service provider as presented by Jeff Sutherland in "Money for Nothing and your Change for Free".

From the perspective of the customer with an Agile contract this implies:
  • The requirements can be changed for free until locked down for development;
  • The Agile approach always ensures a potentially shippable product increment after each iteration allowing for early business benefit realisation;
  • The contract can be terminated anytime either because the value of features do not justify the investment anymore or because of poor performance by the service provider;
  • The financial risk is never more than the early termination fee calculated as a sliding scale of penalty that reduces over time (for example 20% of the remaining contract value).

From the perspective of the service provider with an Agile contract:
  • The incentive is to deliver best value for money to avoid termination of the contract;
  • The termination fee is received as compensation for early termination by the customer;
  • The contract reverts to Time & Material whenever the customer does not comply with the Agile approach anymore.

For a more in-depth analysis refer to the Agile Contract Primer.

Agile EVM Agile EVM on Wikipedia

Earned Value Management (EVM) is a practice used by project managers to monitor project progress, make project forecasts based on extrapolations and finally identify areas of concern. Although EVM is even legally required for specific projects in the US the practice itself is often poorly understood, implemented and used. In Agile projects we often use simple burn-down charts for trend analysis using EVM fundamentals. To explain these fundamentals I have added a special section for Agile EVM on Wikipedia.


The Scrum Process Framework

The Scrum Principles

Although Scrum as a framework is described in the Scrum Guide adequately, for me it was always missing something overarching that stated where we stand for as Scrum. Hence, something like an elevator pitch so that we can instantly explain what Scrum is all about. Finally in Ken's latest book "Software in 30 Days" I found my missing link on page 158 (and only in appendix 3): The Scrum Principles!!!

For Ken's version and full explanation please refer to his book but The Scrum Principles in my own words are:

Scrum Principle #1
Deliver working product increments each 30 days or less to optimise value

Scrum Principle #2
Foster self-organising teams of 6 +/- 3 people to optimise productivity

Scrum Principle #3
Adopt empirical process control to optimise predictability

Cynefin FrameworkThe Cynefin Framework

The software development industry has a poor reputation as it comes to the successful delivery of products/projects. During the nineties we became aware that the inflexible waterfall approach in a complex environment was the root cause. For the last two decades we are trying to shift towards a more emergent approach commonly known as Agile. One of the critical succes factors is the support of senior management. I consider the Cynefin (pronounce ku-nev-in) framework an awesome tool to understand what shift in leadership style is required to start making effective decisions in a complex environment with complex products. I only could have wished that I knew Cynefin earlier.

XP Engineering

Mythbusters: Jamie and Adam

Mythbusters and Pair-Programming

One recent Mythbusters episode dealt with shooting guns using several ways of holding the gun(s) and comparing results. Performance was measured by dividing each score by the time used to shoot a round of ten bullets per gun (this is similar in Scrum when we're calculating the velocity by dividing story points by the length of one sprint). The average results by Jamie and Adam surprised me somewhat but on second thought they confirmed what we already know with pair programming.

But judge for yourself the results in order of decreasing performance (note: I can't recall the exact scores from Mythbusters but the relative order is good enough):

  1. Shooting with 2 hands holding 1 gun - this achieved the best result because accuracy goes up significantly without loosing too much time. This is the same as pair programming with 2 developers using 1 keyboard;
  2. Shooting with 2 hands holding 2 guns - although twice as much ammunition was used, the score suffered from inaccuracy and loss in time because you need to handle 2 guns. This is the same as having 2 developers with 2 keyboards where code integration and communication impacts impact quality and delay the process;
  3. Shooting with 1 hand holding 1 gun - of course this resulted in the least performance (but only slightly!) because you miss the accuracy using your second hand to aim and stabilise the gun, and you miss the fire power of an extra gun. This is situation is the same as having only 1 developer instead of 2 developers.

Although the sample size was too small for any statistical conclusions, I still think it's a nice metaphor: shooting guns is like pair programming!

Agile Planning Planning Poker - The Power of TwoPower of Two

The following guest post from me was posted on the Scrumology website: Planning Poker – The Power of Two

|Courses| |Services| |AgilePM™| |Essentials| |Scrum Master| |Product Owner| |PMI-ACP| |DSDM Scrum| |Agile Compass| |Agile Matrix| |Blog| |About|