Bright Green Blog AGILE, SCRUM, KANBAN, SOFTWARE DEVELOPMENT

It is with much excitement that today we announce the launch of a free version of our Agile Project Tool, Bright Green Projects.

The free version of Bright Green Projects is fully functional and will allow you to;

• Capture Requirements, Issues and Risks.
• Prioritize Requirements and Issues in a backlog.
• Build estimates.
• Plan Iterations and Releases.
• Allocate requirements and issues to developers for build and test.
• Track progress with a Kanban Wall and Burn Down Charts

The free version of Bright Green gives you 3 users forever, please follow the link below to get your account;

https://signup.brightgreenprojects.com/plan/Free

A few months ago we launched the Agile IT Performance Report - a free 8 page report based on 30 questions regarding how your team works together. We can’t take all the credit as we’ve had the help of a team of Academics and Teamwork Experts from Team Management Systems, who are world leaders in work-based, research-proven assessments and feedback instruments.

We are now just short of 1,000 people having completed the quiz around the world, which is an amazing response. We’ve had entire teams complete the quiz, compare their results and then develop ground rules to overcome their weaknesses. Others have used the results at the start of a project to help form their teams.

The quiz is completely free and the results are of course confidential. We’re looking forward to as many people completing the quiz as possible, and will be working with leading academics in the coming months to infer high-level results from the entire data set. We will share the findings with everyone who completes the quiz.

Please find the quiz at http://quiz.brightgreenprojects.com . It will take about 15 minutes to complete and I’m sure you’ll find the results interesting, insightful and helpful for your team.

Up until very recently Agile was seen as a great approach to software development……..for small projects.  Even now, especially in the enterprise space (SAP, Siebel other EPR’s), agile is still seen by some as small-fry, a fun approach for building web sites.  I was recently speaking with an old colleague from Deloitte, who is now a Senior VP for a Software Company that we all know – he didn’t even know what agile was.

The larger the project, the more critical it is to the organisation.  This means that more managers want to be in the loop and constantly informed, the project will have a much larger scope, the project will be very time sensitive with delivery dates, it will cost more and will often be spread out across multiple sites.  Of course, the number of resources required to deliver the project will grow need to grow, to a team much larger than the target team size of 7!

Google, Salesforce, Nokia and many other well known organisations have dealt with this issue not by just growing their team, but by building many small, self-managing teams, working off the same product backlog.

Scaling the Product Owner

The Product Owner is one of the most difficult roles on an agile project.  They have many commitments to the actual team such as attending daily standup meetings, retrospectives and are expected to help the team remove blocks and reduce waste.  They also have a huge commitment to the customer, are responsible for managing the ROI and need to carefully maintain a prioritized backlog of requirements.  In order to gather these requirements they must be meeting with stakeholders, customers and keeping a close eye on the competition.  Not an easy job.

Ideally there should be a 1:1 relationship between a team and their Product Owner.  This isn’t always realistic.  We’ve seen it work OK when a Product Owner looks after two teams – but this is the maximum!

A problem with simply adding Product Owners as the scope grows is that the teams and the product owners will start to work independently and may lose the overall vision and direction of the project.  Before this point is reached, it makes sense to build a hierarchy of collaborating product owners – reporting to a “Chief Product Owner” as explained by Mike Cohn, in his book Succeeding with Agile.

The “Chief Product Owner” is responsible for maintaining the overall vision of the product and distilling it to the actual Product Owners who will be working with individual teams.  This can be scaled by adding many levels.

Scaling the Agile Teams

The approach used by many large enterprises is to tackle large projects with many small agile teams.  A side-effect of this is that as the number of teams grow, the dependencies and interfaces between teams grows with them! An approach to deal with this problem is the scrum of scrums.

The scrum of scrums meeting should occur once or twice a week and one or two representatives from each team should be present.  It should be similar to the daily standup meeting, however, it will take a little longer as there needs to be discussions between the group about dealing with dependencies and how remove cross-team blocks.  The scrum of scrum meeting can be scaled by adding more levels to the hierarchy.

One Backlog

Another problem of having many teams work independently is maintaining vision and direction.  An approach to deal with this issue is to ensure that no matter how big your project, you maintain a single product backlog.  This will allow the “Chief Product Owner” to see dependencies between individual stories and if necessary, direct teams to work on different areas.  For example, maybe it’s better for the “HR Team” to stop working on low priority HR Stories and help the “Finance” team with some high priority Finance Stories.

A problem with having a combined backlog is that the backlog can very quickly grow to many thousands of stories.  We’re currently working with a client that has over 6,000 requirements in their backlog.  In order for the Product Owners to understand and comprehend the work, it’s best to group requirements up in themes or build a hierarchy of requirements under epics.  More than a few hundred, high level requirements are virtually impossible to manage.

Syncronise Sprints and Iterations

Our client with 6,000 requirements currently have five independent agile teams with syncronised sprints.  Unfortunately the teams aren’t really self-managing, however, all the sprints start and end on the same date.  This really makes everyone’s life on the project much easier, as everyone is working to the same deadlines.  The project as a whole are in the same rhythm.  Things can get a little crazy at the start and end of sprints trying to stagger playback sessions with the client so people can be in two places at the same time – but teams can generally work it out!

Communities of Practice

Cross Functional Teams are great, as they allow the team to build a single piece of “potentially shippable software”.  A side-effect of cross functional teams are that like-minded people don’t get to spend much time together.  For example, if you’re a Scrum Master, you are kind of left to your own devices.  Mike Cohn introduces the concept of “Communties of Practice” in his book “Succeeding with Agile”.

A Community of Practice is an informal group of people in your organisation who meet up reguarly to discuss things pertinent to their role.  Informally, all of the Scrum Masters in your organisation may have lunch together each Friday.  This could also be more formal, whereby all UI Designers meet twice a week to compare designs.

Enterprise Agile

Agile and Scrum can scale in an organisation.  Like any large change in an organisation, you can guarantee there will be a high resistance from many areas of your team.  Training of the team, sponsorship from a high level and support from peers and direct supervisors is critical to push it through.

A common fear about agile is that it makes the job of managing scope difficult for your project.  This can be true, however, a golden rule of agile software development is that the scope of each iteration or sprint must be completely locked-down once it begins.  This means no new requirements, no swapping of requirements and also no shifting of the end date.

Allowing a new requirement into the current sprint may increase the satisfaction of the business in the short term, however, there are many serious longer term implications.  The most serious concern is that the business or product owner will not take the process of preparing requirements prior to the sprint seriously and will always feel that things can be “snuck in” if they haven’t done a thorough job of preparing and prioritising requirements.

Another concern is that the team will lose focus and their sense of commitment about what they agreed to deliver.  This is a quick way for the “self managing” team to lose their sense of responsibility.

This is always tricky and requires a high degree of diplomacy, however, the best way to deal with this situation is to push back on the customer and let them know that it will be the first requirement to be included in the next sprint.  If this is still not appropriate, simply stop the current sprint and plan out a new one with the new requirement included.

Quite often we get asked by those new to agile development what exactly an iteration or sprint is? The first thing is that a sprint and an iteration are essentially the same thing, a “sprint” is the term used by scrum, which is the most popular flavour of agile project management.  You’ll find that most agile practitioners use the terms interchangeably.

A sprint is a “time-boxed” period of work, with a closely defined and agreed output.  In the software development world, the  output is “potentially shippable” code.  At the end of the sprint, the “potentially shippable” code is presented back to the client in a playback session.

By potentially shippable, we mean that it has been built, tested, integrated, documented etc. Any task that is required to be undertaken by the team to release it, needs to be done.  It’s very rare that a team will “release” each sprint to production, however, highly agile teams may operate in this manner in certain environments.

Another common characteristic of agile development teams are that they are self-managing.  Given this trait, it’s important that the team themselves agree to what is being asked of them in the sprint and commit to delivering it.  In some ways the responsibility of delivery moves from the Project Manger, to the entire team on an agile project.

At the end of each sprint it’s important for the team to get together for a retrospective.  It’s important that everyone attends and it needs to be an open forum to discuss what did and didn’t work on the current sprint.  As a group you then then to come up with a few changes to make during the next sprint.  This regular feedback is great and really differs from the traditional “post implementation review” or “post mortem” generally done long after the project is delivered.

So in summary;

• A sprint and an iteration are basically the same thing!
• It’s a time boxed period of work – generally 2-4 weeks.
• The output is “potentially” shippable software.
• The team themselves must agree on the scope of the sprint.
• The scope is locked-down once the sprint begins.
• To keep improving, each sprint ends with a retrospective.
• A release is generally made up of multiple sprints.

Whether working on Agile, Scrum or Waterfall projects, it’s really important to remember that user stories and business requirements should only serve the purpose of reminding everyone on the team of conversations and a shared understanding.

Many of us have been in the situation, especially when working on traditional waterfall projects where the requirements are looked at as a contract.  Sometimes this really is the situation, however, if you want to make sure that the business gets what they want, it is imperative that the developers really understand the purpose of the requirement.

An Agile requirements techniques that I have seen really improve “shared understanding” and quality of conversations is to write requirements as simple user stories.  Mike Cohn, who coined the term User Stories, encourage us to write requirements in the form of

“As a <user>, I want <goal>, so that I can <goal/value>.”

Identifying the user helps in writing user centric requirements and the “so what” helps encourage discussions and makes sure that everyone really understands the purpose of the requirement and value to the business.

An example;

“As a caseworker, I can view the date of birth of all patients, so I can tell if the are in our jurisdiction.”

or

“As a Workflow Manager, I can always tell the number of people in the call queue and the wait time, so I can make appropriate resourcing decisions.”

Another tip to improve shared knowledge and discussions is to write an acceptance criteria.  Acceptance Criteria is a simple, black and white statement that expresses what the customer expects to see and can be used by the team to make sure the requirement is complete, or “done”.

Following on from the examples above, useful acceptance criteria would be;

“A date of birth field against the patient in the format of DD/MM/YYYY.”

and

“On a dashboard I can see a live count of people in the queue and the average wait time”

On smaller projects, you may decide to use index cards and write the requirement on the front and the acceptance criteria on the back.  If you are working on a larger project, have many requirements or work with a distributed team, take a look at Bright Green Project to manage all of your Agile Requirements.

Santa Claus and his team of  hard working elves are the latest high profile team to adopt an Agile Approach.  They are believed to be the first large scale team to do so, within the Arctic Circle.

In a recent interview, Mr. Claus said “I’ve been working with this structured, heavily documented, big-bang approach for hundreds of years now – I didn’t know any better.  As of 2010 – the North Pole will be Agile.  Our first iteration will be delivered 25th JANUARY.”

Santa wants to not only give to children, but also to the Agile Community.  He has shared the following for us all to learn from;

1. The workshop builds toys based on a long list of children “who have been naughty or nice”.  This list is in the order that Santa receives requests – his first task will be to prioritize this list.  The most important children, such as those of celebrities, politicians or wealthy bankers will be at the top of the list.
2. Santa will get out of the workshop, stop telling the elves what to do and encourage them to self manage.
3. Rather than spending the entire year working alone in the North Pole, with a single delivery on 25TH DECEMBER, Santa will adopt an iterative approach with a deliverable on the 25th OF EACH MONTH.
4. The most important children will be presented with their gifts on 25th JANUARY.  If they are unhappy with what they receive, Santa will bring the gifts back to the workshop for rework.  The rework will be prioritized against the backlog of other gifts.
5. Not everyone is going to win. Given the high amount of rework expected from the “important” children, it is likely that those children towards the bottom of Santa’s List will not receive gifts every year.  Santa sees this sacrifice as worthwhile, given the most important children will always be happy.
6. Even though Santa will prioritize and ultimately own the “list”, the Elves will identify how much they can build each month and allocate tasks to each other independently of Santa.
7. Gifts will only be considered “done” when they are built, tested, wrapped and the delivery method clearly defined.
8. Children need to move away from heavily documenting their wish lists and make the time for a face-to-face conversation with Santa.  Santa will now accept visitors to the North Pole all year and will also make himself available using video conferencing facilities.
9. Bright Green Projects will be used by Santa, Mrs Claus, The Elves and Reindeer as their Agile Project Management Tool – this simple, web based tool will allow Santa and the team to collaborate and work together.  As it is web based, it will allow him to more easily achieve his ultimate goal of moving to a warmer climate with Mrs. Claus and outsourcing the development process to an offshore team.
10. Rudolph will be the Scrum Master, so long the other Reindeer promise to no longer “laugh and call him names”.