Tag Archive: Agile


The Happiness Index is a pattern taken from Jeff Sutherlands paper ‘Teams That Finish Early Accelerate Faster’ I implemented the pattern with a team a couple of years ago and found it to be a very useful metric. I’m a strong believer in human centred behavioural metrics which inform intelligent decision making.

The Happiness Metric accurately told a story of 6 or 7 months on our team where we encountered a situation where the current backlog we were working on got pulled just prior to release and we went in to a Waterfa(i)ll style 3-4 month  traditional discovery phase.

The way I facilitated this with the team was at the end of the retro I stuck two post-its outside the room with “How happy are you with the company?” and “How happy are you with your role?” on them and asked everyone to stick post it’s underneath on a scale of 1(low) to 5(high) on their way out the room.

happiness-voting

The output was tracked on a spreadsheet and then visualised  in a basic graph.

happiness-index

What is interesting is that the happiness of the team with their roles was substantially more resilient than their feelings about the company. We were a tight knit team and this shows the importance of strong team relationships which can sustain the team through tough times. The Sprints were 2 week iterations so from Sprint 6 to Sprint 01 represents about 5 months. Although every team is different, this empirical data would suggest a mature ‘healthy’ team can support a 4 to 5 month rough patch before losing motivation in their role. In this case a traditional project discovery phase was managed in a typically top down way and left the team in a perpetual spike cycle with no output except for estimates against a growing and churning backlog.

With the index as evidence I worked with the team running workshops and challenging the traditional project management approach to give them hope that there was an end in sight. The knowledge of how the team felt enabled me to adjust my coaching strategy accordingly.

I would suggest that you consider adopting a metric of this nature.

A note on Metrics:

When applying the rule ‘you improve what you measure‘ as distinct from the over used Peter Drucker quote ‘If you can’t measure it, you can’t improve it’, you need to be wary of the negative scenario this creates; in other words whilst you concentrate efforts on improving your measured metric you are likely getting worse in an area that is not being focused on.

Advertisements

There is a lively debate around whether the Death Star could be classed as an Agile Project. I would suggest, that it’s more relevant to look to the Rebel Alliance. The Alliance shows us a good example of a cross-discipline hyper-productive Scrum Team in action.

The Death Star project does have a clearly defined Vertical Slice, which would seem to point to an Agile approach. The planet-destroying superlaser was delivered as a functional artifact whilst other less important features were dropped.

On closer inspection however we could surmise that the legacy command and control management structure has produced a flawed ‘Scrumbut’ implementation.

The failure to embrace good Planning and Engineering Practices left the weapon with a fatal flaw – open exhaust conduits that allowed it’s destruction.

Don’t be too proud of this technological terror you’ve constructed.” Darth Vader

Clearly a reference to ‘gold-plating’. It seems that Darth Vader was not attending the Daily Meeting or Sprint Review. I’ll leave you to decide whether Darth Vader was a Product Owner or Scrum Leader.

The Death Star was an Agile Project | Hacker News

1] Ackbar, Return of the Jedi “It’s a trap!” [2] The Emperor, Return of the Jedi “As you can see, my young apprentice, your friends have failed. Now witness the firepower of this fully ARMED and OPERATIONAL battle station!” qa-ds1-15215: I was checking out the design and noticed that thermal exhaust port AH-51 is open to the world.
Death Star II As an Agile Project

So, Vader takes an Agile approach. He prioritizes the features list (“Look, we really need the big laser thing; our customers will just have to come to us at first.”), and he works in vertical slices. At the end of the movie, it seems to have paid off.

A recent marketing campaign for MS Project postulated that Luke Skywalker achieved his goal in Episode IV using a traditional Gant Chart. I’m somewhat sceptical – the intuitive nature of the force and the distributed nature of the Jedi are far more akin to a self-organising Agile model.

The Episode IV team comprising Luke, Han, Leia, C3P0, R2D2, Chewy and OB1 is clearly a hyper-productive, cross-discipline Scrum Team. Conforming to the 7+ or -2 team number ‘sweet spot’. The team follows the pattern of an effective geographically distributed(at times) Scrum.

InfoQ: Jeff Sutherland: Reaching Hyper-Productivity with Outsourced Development Teams

Nathan Marz explain Storm, a distributed fault-tolerant and real-time computational system currently used by Twitter to keep statistics on user clicks for every URL and domain. Founding members of the ICAgile Consortium, Ahmed Sidky and Alistair Cockburn, discuss IC Agile, along with Bob Payne, a consultant, coach and trainer.
Distributed Teams Content on InfoQ

InfoQ.com (Information Queue) is an independent online community focused on change and innovation in enterprise software development, targeted primarily at the technical architect, technical team lead (senior developer), and project manager. InfoQ serves the Java, .NET, Ruby, SOA, and Agile communities with daily news written by domain experts, articles, video interviews, video conference presentations, and mini-books.

I was recently thinking about a definition of ‘self-organising teams’.I quickly came to the conclusion that collecting examples of self-organising behaviour was the best means to help this process.

My team approached me because they were confused about how we calculated Capacity for a Sprint. The team had two new members and I was reducing their capacity down to 50% and therefore the number of hours that were available for project work by the same amount. @phil_12d3 (Twitter tag) pointed out that this made no sense as everybody was at work for the same amount of time. The result of the variance I added, was that the newer members of the team ended up filling up their time with Support work. My attempt to measure and estimate personal capacity for the Sprint was flawed. We worked through a few new ideas as a team to find a better and more accurate way to estimate the number of productive hours available.

Phil eventually honed the rough calculations we made on a white board to the infographic below:

 

 

 

 

 

 

 

 

 

 

 

 

 

Creative Commons License
All work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

The hours are broken down between Project work, Support time, Meetings and Study time per developer. This made for a far simpler calculation.The variance in how long different tasks would take, was applied via a modifier during the final phase of Task Estimation. I was slightly uncomfortable with the necessity of allocating tasks per team member at the beginning of the Sprint. The preferred route would be a fully multi-disciplinary team that chose which tasks were worked on a voluntary and priority basis. My intial misgivings were overcome by the enthusiasm of team members over the ability to measure capacity and thus delivery on a daily basis.

To return to my original point; the process we went through as a team to develop this crucial process is an excellent example of a self-organising team. The team was not only focused on delivery but also the mechanism to improve the estimation and process of the Sprint.

Can you identify examples of self-organisation within your teams?

Gamification is part of a new vocabulary which seeks to describe the fusion of different disciplines. As I’ve read more deeply about Gamification, I’ve come to realise that the concept is easily identifiable within the Scrum Framework. For an example the Daily Meeting has many facets which seek to open channels of communication through Gamification. The Daily Meeting is built around a few simple rules which you can easily set in to a game metaphor (in bold):


1. The same time every day – The fixture
2. All the team must attend – You must be part of the team to play
3. Team stands-up and huddles – Many games engender a sense of proximity to ensure involvement and to provide an immersive experience
4. Takes place in the same place – The pitch
5. Time-boxed to 15 minutes – The game is time-limited to promote intensity
6. Early meetings should adhere to three questions – Simple rules promote inclusion and participation

  • What did I do yesterday
  • What will I do today?
  • What’s in my way?

7. Use a speaking token – A ball or baton is thrown from player to player
8. Signal the end – The whistle is blown and the game is over

The Scrum Master acts as a referee facilitating the meeting but not interfering or running the meeting. The Daily Meeting is a perfect example of how Gamification can help us be more effective at delivering a ‘product’, managing our time and transforming the world of work.

The Scrum Framework introduces Game Mechanics to the workplace and by doing so delivers business advantage.

Have you used Gamification in your products or workplace? Is ‘Gamification’ part of a new vocabulary or empty hyperbole?

Further information on Gamification

A great place to start looking at real world examples of Gamification is this article by @adachen:
http://adachen.com/2010/10/04/what-is-gamification-and-real-world-examples-of-it/

Sharleen Sy has written a good article on why Game Mechanics work:
http://stratsynergy.wordpress.com/2010/09/12/motivations-and-personality-types/

Seattle’s Tech Flash has a great article on how Gamification has impacted business and science:
http://www.techflash.com/mobile/seattle/2011/02/how-the-psychology-of-games-is.html

Microsofts Ribbon Hero is an example of Gamification of software applications:
http://www.officelabs.com/ribbonhero

I previously wrote about the benefits major marketing agencies were experiencing by implementing Agile techniques within their business. Taking that concept one stage further I’ve re-engineered Mike Cohn’s ubiquitous Scrum framework diagram to show how Teehan and Lax’s six steps to Adaptive Marketing can be applied to this process.
Mike Cohn’s Scrum Framework Copyright 2005 Mountain Goat Software
Adaptive Marketing Using The Scrum Framework  – Diagram
Creative Commons License
All work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

The Six Steps are as follows:

1.     Product Backlog

The agency and client define the objectives of the engagement and establish several key performance indicators. The first step is all bout establishing the vision with the client and producing a product backlog with the team.

2.     Sprint

The creative team is dedicated to the project for a set period of time allowing them to focus on the task. Creating the Sprint is a familiar concept to Agilists and it makes perfect sense in the context of a marketing campaign.

3-5.     Meetings

Steps 3 -5 are encompassed in the Empirical framework of Scrum. Ideas are rapidly developed, tested and deployed
Ideas evolve and adapt over time. Performance is closely monitored allowing the team to make adjustments.

The combination of Sprint Planning, Daily Meetings, Sprint Review and Sprint Retrospectives all support an inspect and adapt approach to marketing.

6. Sprint Review and Retrospective

Project success is determined by achieving the KPIs. The Sprint Review meeting covers the necessary KPI’s to ensure that all activities match a state of ‘done’ and whether the process and campaign were successful.

Using the Scrum Framework gives transparency to the Adaptive Marketing process, a corner-stone of the Agile approach.

Do you practice Adaptive Marketing or have you implemented Agile at Enterprise level? Have you used the Scrum Framework outside of Software Development? How did it go?

I’ve blogged before on the role of being a designer in a Scrum Team. I thought it would be interesting to micro-blog my actual experiences of participating in the Sprint.

Day 1
First day of being back in the Sprint with the developers. I’m feeling the subtle pressure (or is that motivation?) to get my tasks done on time. We are working on a high-profile project and I can’t afford to hold up development by not having the design work completed.

Day 2
The wireframes have been created but the layouts are all wrong, so I need to pull my finger out! The 960.gs CSS framework is a great help in the creation of the wireframes.

Day 3
I forgot to update my tasks before I left last night. Consequently we are behind on our Burndown Chart. I have to confess to the team that I didn’t practice what I preach. A humbling experience and I will definitely remember tonight and also cut some slack to my team in the future if this happens on the odd occasion.

Day 4
Chris Brogan recently said that “doing is more fun than planning”. Turns out he’s right. I’m enjoying keeping track of my tasks and having the opportunity to move my post-its across the board to ‘Done’. I think if you haven’t been in the Scrum you are losing a vital perspective on how the Sprint dynamic encourages a feeling of success.

Day 5
The post-its that have been bought from a local supermarket keep falling off the board. I had heard the team mentioning this, but hadn’t completed appreciated how annoying it is. The next purchase of post-it’s will be the genuine thing.

Day 6
I’ve cheated and added some additional screens to an existing task. I can’t decide whether this is utilising Scrum in a flexible way or I’m committing a Scrum sin. I’ll pick up the issue in the retrospective with the team.

Day 7
The Sprint has blipped. We have a developer unexpectedly out for two days. That’s a lot of ground to make up and we may need to take something out of the Sprint to compensate.

Day 8
In the Pre- Sprint Planning Meeting with our Product Owner we discussed a new design for a Blog Template. I promptly forgot to include that in the task so now I have to make up the time. In this situation wireframes are a great solution. Wireframes provide the developers with the information they need to get going whilst buying some time to complete the design.

Day 9
Being more physically involved in the Sprint has made me realise that the whiteboard could do with an overhaul. The board should be at the centre of the team, radiating information out to the wider business.

Day 10
I’ve gained final approval the last of my design work so my active tasks in the Sprint are set to Done. I’m back to the role of Scrum Master but I’ve learned a lot and been reminded of how it feels to be ‘in the Sprint’.

Day 11
I was reading ‘Agile Coaching’  and came across the following link:
http://www.xqa.com.ar/visualmanagement/2009/02/visual-management-for-agile-teams/
Combined with my recent interest in visual thinking, this opened my mind to the possibilities of expanding the purpose of the current whiteboard. The current board is simply a ‘task board’ and there is a clear opportunity to make it a ‘team board’.  We are shortly transitioning to VS 2010 Agile 5.0 templates. After that change has been completed I’ll talk to the team about shaking up the whiteboard.

Day 12
It’s the last day of the Sprint and we managed to bring it in on-time. This is a great achievement as we lost some resource and velocity mid-sprint. I will be including my work in future Sprints, as it’s been a great reality check.

Are you a designer in a Scrum Team? Should design work be included in the Sprint? Let me know what you think.

What I have quickly found is that it’s really hard to protect developer’s time on Blue Sky Days. We had two issues which I would have usually rushed through, but this is the first time I had awarded Blue Sky days to the team. It would have completely undermined the concept if I’d asked them to do this work. I made a pragmatic decision to hold back the work but it was difficult not to interrupt their day.

I ensured that the team understood that they had the time to investigate new development work or any technology that interested them. In my absence a developer was approached with a serious pricing issue – I was glad to hear on my return this had been dealt with in a timely manner. I was also gladdened that the principles of self-organising had shone through. It does show however that the Scrum Leader has to be ever vigilant to protect developer’s time if the concept of Blue Sky Days is to have validity.

The pot of gold is somewhat elusive but if we allow teams the chance to explore, they might just find one.

Are Blue Sky Days worth their weight in gold?

Six steps to Adaptive Marketing

Marketing like UX is a balance of Art and Science. The role of marketer is like an architect, musician, conductor or cinematographer. This is the message I brought back from this year’s Web Trends conference I attended in London.The complexity and flux which has become synonymous with the Marketing landscape naturally dove-tails in to an Agile approach. That approach produces ‘Adaptive Marketing’.

The phrase ‘Adaptive Marketing’ was coined last year in a Forrester report and describes how Agile practices can be utilised to facilitate the marketing process. There’s a great definition of how Scrum works for marketing purposes, hidden in an article on the Teehan and Lax site:

  1. The agency and client define the objectives of the engagement and establish several key performance indicators
  2. The creative team is dedicated to the project for a set period of time allowing them to focus on the task
  3. Ideas are rapidly developed, tested and deployed
  4. Ideas evolve and adapt over time
  5. Performance is closely monitored allowing the team to make adjustments
  6. Project success is determined by achieving the KPIs

Adaptive Marketing is further defined by:

  • Removing the formal annual budgeting process
  • Removing medium to long-term media buying
  • Adopting short, measured, iterative plans
  • Allocating money for high-level visions not specific media
  • Adapting based on real-time consumer feedback and other data

An Agile approach to marketing reacts to the heart and soul of what the brand stands for. The catalyst for this is defined by the pull of brand influencers in the Social Media space and is not pushed by the business.

Agile offers the opportunity to create technology driven, data-fuelled campaigns that respond in real time to the shifting Social Media and Marketing landscape.

Do you think there is a place for Agile practices in Marketing?

Further links on Adaptive Marketing:

So what exactly might ‘Adaptive Brand Marketing’ be?
http://bbh-labs.com/so-what-exactly-might-adaptive-brand-marketing-be

The practice of Adaptive Marketing
http://www.teehanlax.com/blog/2010/06/14/the-practice-of-adaptive-marketing/

The Forrester report
http://www.forrester.com/rb/Research/adaptive_brand_marketing/q/id/55526/t/2

Razorfish embrace Agile:
http://www.clickz.com/clickz/news/1725751/razorfish-disses-big-idea-pushes-iterative-model

Below is a link to a Blog Post by Robert C Martin. He is colloquially known as Uncle Bob and was a pioneer of XP practices. I’ve recently been booked on to a Scrum Leader Certification course and have seen many posts on the perils of employing Certificated Scrum Leaders with little or no commercial experience.

Uncle Bob goes further in his critique claiming this trend could create the type of elitism that made the Waterfall software development model implode. In an explanation of why waterfall failed he says:

“There were the elite Architects, Designers, and System Analysts who did the real engineering by satisfying the first two phases of the waterfall.  And then there were the grunts who actually had to make everything work in the final phase.  When the project got behind schedule, it was the grunts who worked overtime.  When the project failed, it was the grunts who bore the blame.”

I believe I fall in the justifiable category of existing professionals who are seeking Certification to further my knowledge of Agile/Scrum. As Scrum Leaders we need to be mindful that we are here to serve the developers and help them get better at what they do by applying those practices.

Give it a read, we can all learn from the mistakes of Waterfall.

http://thecleancoder.blogspot.com/2010/11/what-killed-waterfall-could-kill-agile.html

Uncle Bob followed this up with a definition of a valid certification route:

http://thecleancoder.blogspot.com/2010/11/certification-worth-having.html

Are you getting Certification for the right reasons?
As an employer would you choose a Certified Scrum Leader over a more experienced uncertified candidate?

Somewhere over the rainbow

Well worth watching this, it’s only 20 minutes:
http://blog.ted.com/2009/08/the_surprising.php
I recently watched one of the very good TED talks (see link above – I’d highly recommend you take a look at these). The talk was about the surprising truth that incentives, rewards and bonuses do not motivate teams to perform better. At best they encourage a plateau of performance, at worst they drive performance down. There’s a great comparison at the end involving Microsoft.


The primary message I took from the talk was that we need to find alternative ways to motivate our teams. In consultation with senior management we decided to institute an informal implementation of Blue Sky days.

The Blue Sky days concept is simple; empower people to spend time doing what they enjoy and allow them to investigate new technologies or ideas that might ultimately deliver innovative solutions to problems or products. A defining feature of the scheme is that it is driven by the individual or team and it’s hands-off by management. The same idea is employed by Google and has generated the energy and enthusiasm in many Google projects including Maps and Wave. Blue Sky Days are awarded at the discretion of the Scrum Leader for outstanding effort during a Sprint.

For example my team recently finished a Sprint 2 days early – this was due to some hard work and innovative solutions to delivering a project. I awarded Blue Sky days to two developers.