How do you spot a self-organisng team?

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:

 

 

 

 

 

 

 

 

 

 

 

 

 

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?

Adaptive Marketing Using The Scrum Framework

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

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?

The Pot Of Gold – First use of Blue Sky Days

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

Kindly reproduced from http://commons.wikimedia.org/wiki/File:Chameleon_2006-01-contrast.jpg

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

Uncle Bob’s Guide On How To Kill Scrum

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.

Designers v Developers

The amusing Infographic created by Six Revisions:

http://bit.ly/aN8AHh

Started me thinking about the role Scrum has in breaking down barriers between disciplines.

Scrum teams derive their strength and ability to deliver diverse projects by focusing different skill sets in to one team. The input of design or testing is similar to Pair Programming in that the developer works closely with a team member from another business discipline. Partners from testing, design or other areas are swapped in and out depending on the needs of the project.

Working as a designer in a Scrum team I work closely with the developers to achieve excellence in User Experience. The team has recently won an industry award for delivering outstanding functionality in a high-profile website. The award was achieved by the marriage of technical excellence and elegant User Experience.

The fusion of different disciplines in products such as Microsoft Blend, Adobe Flash and Xcode’s Interface Builder reflect the needs of an audience, which expects a good user experience in a product that ‘just works’. Agile software development breaks down barriers and encourages communication between team members, which helps us to produce great products.

The mythical ‘designer/developer’ or devigner that excels in both disciplines is just that, a myth. 
The strength of the Scrum approach is that it encourages developers to understand and get involved with the User Experience and designers to appreciate the technical excellence required to make a product fly.

It’s a party not a war – or do you disagree?

From Zero to Hero

What do you do when the business puts you under pressure to start a new project or business process and you don’t have the information you need to get going?

Iteration Zero is a great idea if you have a new team that need to orient to Scrum methodology or you have a large project that needs research or specialist equipment.

The concept is simply that you plan out what will be required to start the project. There may be a situation where an Iteration Zero is required to build the Product Backlog before starting the process of estimating and prioritising.

Peter Schuh has an excellent review of Iteration Zero, which also covers support and refactoring:

http://peterschuh.com/?p=129

If you utilise Iteration Zero, let me know how it goes.

Timing is everything

I attended the Webtrends Engage conference this week in London and it was by far the most useful conference I’ve attended for years. Partly this is due to the current climate in digital marketing which is rich with possibilities and potential. It struck me that the timing of this event was perfect and that ‘timing’ is a major success factor in Agile methodology. You could say in Scrum ‘timing is everything’.

I’ve run Sprints in varying lengths between one and four weeks. The perfect length of Sprint is largely based around the changing needs of the team and how the Product Backlog is shaping up at any point in time.

Early phases of a project often benefit from short one week Sprints that offer fast proto-typing and quick iterations.  The fast iterations that are a product of Scrum, offer stake-holders the chance to adjust their requirements and give the team the chance to hone their estimates to bring them in-line with the technological challenges.  As projects mature and become more stable they offer the ability to extend the Sprint to three weeks.

A team in transition may also benefit from shorter Sprints. We recently lost our lead dev from the team and quickly it became clear that closer management of the team was required to ensure consistent delivery. The Sprints have now started to extend more toward 2-3 weeks as the confidence of the team has re-built and management confidence in the team to deliver has increased.

Our dirty little secret

Yes, like all Scrum teams we have a ‘dirty little secret’.

Our secret is we don’t use Story Points.( Queue –  Ken Schwaber running screaming from the building) I’m keen to right this wrong so have been delving in to the world of Story Points;

What are they and why are they important?

I was under the complete misunderstanding that Story Points are a measure of time. I have a industry training in Project Management with Gantt Charts, Network diagrams and Critical Paths.

The abstraction of time to plan capacity for a project seems completely alien to me.  I read, listened and watched videos on the subject and suddenly realised that the concept is quite liberating. Simply put:

“A Story Point is a measure of how difficult a task is”

Many Scrum teams use Small, Medium, Large and Xtra Large to classify the size of projects and Mike Cohn talks about estimating using distance as a concept. A quick job is near, whilst a difficult or complex job is far away.

I will be pursuing Story Points in a simple 1 (Easy task) – 10 (Difficult task) range. There is the added impetus that very shortly we will be using the MS Agile 5.0 templates in TFS and these strongly support the use of User Stories and Points.

I’m looking forward to liberating the team from worries about being locked down to deadlines or having no clue how long a User Story will take. We should rapidly reach a point, after 2 or 3 iterations where we know how many story points we can accept in to a Sprint. I’ll let you know how it goes.

Mike Cohn on Story Points (short video):

Mike Cohn on Story Points (text):
http://blog.mountaingoatsoftware.com/should-companies-measure-productivity-in-story-points-ideal-days

Brief discussion on the use of Story Points :
http://www.infoq.com/news/2010/03/story-points

Long discussion on the Scrum Alliance Group website, on the relative merits of Story Points:
http://groups.google.com/group/scrumalliance/browse_thread/thread/955dc287638e69f5