Quite often, however, consultancies will track development tasks independently to the way they track and invoice for time.  I.e., the development team will use a Kanban wall to track tasks and time spent, and then a project manager will fill out a separate time sheet at the end of the week/month to bill the client.

This duplicated effort of tracking tasks then invoicing separately is considered ‘Waste’ on an Agile project.  Consultancies should have their task tracking process automatically integrated into their invoicing process – so the action of updating a Kanban wall results in a time sheet automatically being created with associated tasks/times.

At Bright Green, we often work on Agile consultancy projects.  We recommend integrating with FreeAgent using their APIs to enable automated time reporting from an electronic Kanban wall.

Objective: Gain a better understanding of the advantages and disadvantages of various Agile tools

Tools Compared: Bright Green, Rational Team Concert, Rally, VersionOne

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

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.

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.

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.

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.

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.

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”.

Had a Big Mac lately?

I’ve got a good excuse for you – as an experiment to increase the productivity of your team.

Did you know that if you go to a McDonalds drive-thru at a certain store in Missouri, the person on the other end of the speaker is actually 900 miles away in Colorado? The operator in Colorado takes your order and keys it into their system, it is then relayed to the kitchen 900 miles away where your burger and fries are thrown together? Oh yeah, they also take a digital photo of you so they can be sure they give the order to the right customer!!

The next step for them is to outsource this to India and begin taking orders from multiple restaurants.

I got this story from a great book I am reading called ”The World is Flat” by Thomas Friedman and was shocked and amazed at some of the things that globally distributed teams are achieving.

Another great story was about how doctors in certain emergency departments can actually send xrays and scans to the other side of the world, with the help of the internet for diagnosis.  This is not to save money, it is to make sure the best doctor in the world is looking at your problem.  This technology is also really helping smaller hospitals who don’t have the specialist staff all hours of the day and night.

Forming a new team on a project is hard.  You need to make sure that all members have the appropriate technical and business skills, that everyone gels and can work well together and that as a team and that you cover off the nine key areas of high performing teams.  Pretty stiff criteria.

We are finding that our Agile Project Management Software is particuarly helpful for distributed software development teams.  As Bright Green Projects is completly hosted in the cloud, the team can all work together on requirements and issues, plan sprints and keep up to date with the status of their project, no matter what the location.

Working together in the same room is perfect – but distributed teams can achieve amazing things given the right tools.