1. Don’t call it ‘Agile’. The word ‘Agile’ can come with bad connotations such as ‘corner cutting’ or ‘passing fad’, which makes companies skeptical about adopting the framework.  Many of the agile practices however, can be used in isolation to promote your cause.  Start to introduce concepts such as ‘prioritized lists’ and ‘kanban visual boards’, without calling them ‘Agile techniques’.  People will start to see the benefits and not even realise they’re doing Agile.

2. Death by Trial. People don’t want to hear you endlessly evangelise the concept of Agile.  You need to show success in order to get adoption.  The best way to do this is to run a 2-week trial iteration.  Ask the business to give you their 100% trust for the entire duration of the iteration.  In return for their trust, tell them that ‘they win’ if you can’t deliver and they’re not impressed.

3. Phone a Friend. It’s important to have allies when introducing new concepts to any environment.  Find a champion within the business (Project Manager, Stakeholder) and show them how their life will be easier with Agile.  You could, for example, highlight to a PM that since the team is responsible for updating tasks themselves, there are less day-to-day management responsibilities.  You could also highlight to a key stakeholder that there’s better risk management, because the constant plan-implement-review nature of agile detects problems earlier.

4. Make them feel they’re not alone. To win over the the business’s support, you can show examples of industry leaders in this space.  One example would be to show how projects at NASA are run in an Agile way.  NASA use a traditional project lifecycle of: Understand Problem / Establish vision / Architect / Plan / Resource / Execute / Measure.  But within this lifecycle, they use 4-week iterations.  The benefits they’ve seen are: regular tangible deliverables, users being able to add/change features with every iteration and users not minding as much if projects are late.

5. Listen to them! Ask the business about the challenges they’re facing on their current projects.  Provide an example of how Agile could potentially address each challenge.  The business will appreciate that you’re listening to them and trying to solve their problems, rather than just evangelising agile.

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

Last month we decided to try something, its not a new idea, and many companies have done it before us.  The idea - give our entry level product away for free.  For Bright Green Projects this is our personal plan – one user accessing one project. This normally costs $24/month.

Some people also refer to this as the Freemium model.  Skype price their product like this, Spotify do it, LinkedIn does it etc.

We have spent so much time talking about this and a lot of people are pretty interested in it, so I thought I’d blog about it.

5 Reasons For

1. Everyone loves free stuff

By giving our most basic product away for free – we hope we will attract potential customers to take a look at our product. Let’s hope they try Bright Green Projects on a small piece of work and  love it. Fingers crossed on a bigger project, they’ll upgrade to a paying account and use it with their whole team.

2. Free breaks down barriers

As our personal plan is free, people don’t even have to think about price, unless they really like our product and are thinking of having their whole team use it.  Great!

3. The Product Champion

We generally find one person will drive the product evaluation and will then just “show” other people in the team how it works etc. Giving away a personal plan free means that the “product champion” can really take their time and get to know Bright Green, before even worrying about money.

We offer a free 21 day trial on all of our paying plans so the whole team can try it first at no cost too!

4. Word of mouth

Most people find out about our tool through word of mouth.  We feel that more people will be encouraged to recommend our product to someone if the personal edition is free, as there is no money involved.

5. Let’s take it slow….get to know each other first

We really distinguish ourselves from our competitors as we offer great service and consultation to our customers.  We are all ex Project Managers, Analysts and Developers and our customers like that.

Once the customer gets know know us and understand how seriously we take this business, they’ll be more comfortable introducing Bright Green Projects to the rest of their business.

5 Reasons Against

You can’t please all the people, all of the time.

We have been advised by many people not to do this at all…..especially those who have been in the sales game for a long time.  A few reasons against offering a free version of Bright Green Projects.

1. It undervalues your product

If you give it away for free for one person, the customer will feel that they should never pay for it?

ie. Nothing for 1 user, should be nothing times 3 for three users? right?

2. Tire Kickers

We are all about our service. So we can’t exactly not offer it to customers on our free plan. The concern is that we will spend all of our time supporting customers who may actually never even pay for the product!

3. Fear

What if they take advantage of your generosity and share logins, put a huge strain on your infrastructure and cost you loads of money?

4. You’re running a business, not a charity!!

Enough said.

5. Nothing’s really free. In the end you always get what you pay for.

There are already many free Project Management Tools in the market, which are perpetually in beta, supported with advertising or that are free….for now!  We have also seen products that have been launched in order to advertise another area of their business such as consulting, training or development.

Bright Green Projects has been built from the ground up as a commercial Project Management Tool – we make money by selling licenses, most of the money we make, we put back into development, to keep iterating and evolving.  Do we want to be associated with free, potentially lower quality services?

Would love to hear your thoughts? Good idea or not?

If you are interested, take a look at our Agile Project Mangement Tool ……it’s free after all!

The communication problems associated with non-collocated teams are becoming a thing of the past due to advancing Internet technologies.  It’s becoming easier to pick a cost effective global team with the best skills, rather than selecting the immediate people around you who are available. Environmental concerns also mean that business travel is becoming less common. Additionally, working from home 1 or 2 days a week is catching on.

So what are the implications for Agile teams? I have heard many negative opinions from scrum coaches and trainers that virtual whiteboards don’t work – but is this looking to the past and not the future.  If virtual whiteboards don’t work is it because Agile approaches need to be adapted to cater for the way things will be rather than the way they were.

Should we review the Agile ideas of 2001 and adapt them to the coming decade? Is it time for the taskboard wall to fall and the virtual wall to rise? Is it time to be globally agile and to develop Agile Project Tools that enhance the creativity and diversity that a virtual team can bring?

Let me know your comments – either ‘for’ or ‘against’.