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.

From day 1, we made the strategic decision to be cloud only.  All of our servers and capital infrastructure are outsourced.  We have no central office and the only hardware we physically own is our laptops.  This decision was made not only for cost reasons, but to save time and increase flexibility.  We wanted a quick, efficient, reliable solution to get us through the start-up period, that could be instantly scaled up 1000 times for when we went to market.

Here are some steps we followed from inception to become a completely cloud only company:

1.) We set up Google Apps for all of our productivity applications such as email and document management.  In less than half a day we had the full capabilities of an exchange server for a fraction of the cost.  Integration with the iPhone meant we could access email/calendar/contact lists anywhere at any time of the day.

2.) It became apparent that we needed a CRM system to keep track of our prospects and customers.  We signed up for a Salesforce account, and started feeding the prospects in.  With cloud computing, enterprise applications such as this are instantly accessible by all.

3.) With an email, document management and CRM system in place, we needed a cheap way of phoning people internationally.  Skype was the perfect choice, allowing us to make cheap sales calls and also collaborate internally.  The video conferencing capabilities meant we could easily and efficiently conduct meetings with our developers and designers on the other side of the world.

4.) When it came time to start build of our product, we needed a scalable infrastructure, a detailed security plan, and a disaster recovery strategy.  We pretty quickly found a data center that had an international reputation and satisfied all 3 of these requirements.  As a bonus, they also offset their carbon emissions, which was inline with our company ethos.  Their tiered plans enabled pricing efficiency during our development phase, and instant scalability for our test and release phases.

5.) Towards the end of our product development phase, we needed to get word out there about our product, and establish an initial group of beta testers.  We made the choice to go with WordPress, because it allowed us to manage our website and blog in one.  We used blogs to attract prospects and recorded their details using our website.  In just 3 weeks, we managed to sign up over 600 global prospects for our pilot program!

6.) After a very successful pilot period, we launched our product to the global public and soon had customers throughout North America, the UK, Australia and New Zealand.  We needed a way of conducting online meetings with our customers, as an alternative to the expensive travel associated with face to face communication.  We used web conferencing tool GoToMeeting, enabling us to line up back to back, cross-continental meetings, all before lunchtime.

7.) As soon as we launched, we started using our own agile tool to manage requirements, risks, issues and actions.  We had a steady stream of enhancement requests coming in from customers that needed prioritizing and assigning to our global team members. This enabled our distributed development team to collaborate and ensured they were always working off the same page.

The actions listed above have enabled us to quickly and cost effectively grow over 12 months.  Every part of our business can be dynamically scaled up or down, allowing us to compete on a global scale with companies 100 times our size.  This would not have been possible just a few years ago!!  2009 has seen the biggest increase in adoption of cloud computing than ever before.  Cloud computing is no longer just a buzzword, it’s here to stay, and if you’re not there yet, then get your head out of your ass.

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

A starting point for all teams is to understand the nature of the work that teams need to focus on.   The Team Management Systems Types of Work Wheel identifies eight distinct ‘Types of Work’ that need to be undertaken by all teams, regardless of their industry.  There are important learnings here for our industry of Agile Project Management.  The eight work functions are listed below, with the approval of Team Management Systems.

Types of Work Wheel

The Advising function is associated with the gathering of information from all stakeholders and responding quickly to changing requirements. It involves keeping up-to-date with developments inside and outside the organization and passing advice on to others to help them in their work. It requires a transparent flow of knowledge of ‘what’ is going on and ‘where’, and a focus on ‘consulting skills’ so that information can be gathered quickly, accurately and effectively.

The Innovating function involves generating new ideas and new ways of doing things. This requires the development of creative problem-solving skills so that the team remains one step ahead of its competitors. To do this well requires original thought, imagination and innovative thinking.

The Promoting function is concerned with the identification of opportunities and the ’selling’ of these opportunities to others, both inside and outside the organization. It often involves the application of influencing skills and the making of presentations to others. It can also involve communicating the team or organizational ‘vision’. High visibility throughout the organization may also be required.

The Developing function is associated with the turning of concepts into ‘reality’. Ideas are worked on to produce practical products and services. In many cases it may also involve developing workable and practical solutions when problems arise. Agile teams need good analytical skills so that requirements can be quickly prioritized, enabling accurate estimates of iterations and burn down charts.

The Organizing function involves organizing people and resources efficiently by setting clear goals and objectives and making team members accountable for their actions. It is also associated with the implementation of quick effective action when problems occur, so that the planned outputs are always capable of being achieved. In summary it is the function that ensures that the work of the team is structured and focused towards common objectives.

The Producing function focuses on outputs, ensuring that iterations are completed to high standards of effectiveness and efficiency. It is the function associated with the regular delivery of releases and other services. It requires a systematic approach to work and an emphasis on the delivery of products on time.

The Inspecting function requires an attention to detail and an emphasis on the monitoring of systems, contracts and outputs. It is also associated with a focus on accuracy, ensuring that work outputs are always delivered to the right quality. This function is the classic control function where procedures are regularly monitored for their efficiency. It’s often a core feature of the sprint review process.

The Maintaining function is a support function which ensures that proper standards of conduct and ethics are upheld and that quality is maintained. It is also associated with supporting others in the team so that the team processes follow agreed ground rules. Personal conviction and loyalty are often important to this function as is an interest in helping others.

Work Preferences

For teams to be high-performing it’s essential that these eight Types of Work are done well. But Team Management Systems has discovered that rarely does anyone actually enjoy doing all of these functions.   People show distinct ‘work preferences’ for maybe just two or three of these activities.

Work Preferences are dimensions of individual differences in tendencies to show consistent patterns of relationships, thoughts, feelings and actions in the work environment. Work Preferences determine the conditions we all set up to allow our mental and psychic processes to flow freely.  Preferences are usually transparent and are often the first thing we notice in others – ‘He’s rather quiet, isn’t he?’ or ‘She never stops talking.’  Some people prefer to think things through on their own whereas others need to talk out loud to clarify their ideas. Preferences are readily visible to others and are usually the basis of first impressions.

When we are working to our preferences we set up conditions where our psychic energy can flow freely.  If we are more extroverted we like work where there are lots of interactions with others, both inside and outside the organization.  If we are more introverted, then we like conditions where we can work on our own with few interruptions and a minimal requirement for meetings. Under these conditions our energy can flow freely with minimal resistance.  Just as electrical energy generates heat when it meets resistance so our psychic energy generates tension and stress when it has to flow through areas that are not our preference.

I have a preference to work in the Advising and Innovating areas on the Types of Work Wheel and I don’t really enjoy Promoting or Organizing activities, so wherever possible I’ll spend time thinking about new ideas or finding out as much as I can about the project.

What happens in an Agile team is that there’s likely to be an imbalance when you look at the work preferences of all the team members.  If everyone is like me then there’ll be a tendency to give priority to making changes and incorporating the latest ideas.  Teams like this may have the weakness of never tracking their burn-down charts!

Other weaknesses occur if everyone enjoys just Organizing and Producing.  Your team may be well organized and on-target but is it really delivering what the stakeholders want or indeed need?

So, if your Agile Team is to be truly effective you must understand the work preferences of all team members and look at the preferences balance.  It will give you an immediate picture of strengths and weaknesses, as far as teamwork is concerned. Information like this helps ensure that everyone’s work preferences are matched to the critical demand of the job they have to do.  Where the match is high, our energy flows freely, we are more likely to enjoy our job, stress is lower and we feel happier at work.  But all eight work functions must receive the priority they need and never be relegated to lower importance.

Is your team coping with working in an Agile way?  Take the free Agile Performance Quiz now and rate your current or future Agile project. You’ll get a free 8-page assessment of what you think about your team’s performance.

For these ideas to work in practice Agile team members  must know something about teamwork and this means understanding a lot about human behavior and why people do the things they do!

Agile team members are usually composed of highly skilled knowledge workers with strong values of Independence. Some are worth more to an organization than the people who manage them!  Many software developers are quite introverted, preferring to interact with their computers rather than people.  In my experience, companies hardly spend any time on people skills and nothing on the even more difficult concept of what people need to do to ‘self-manage’ into a high-performing team.  I’ve had to learn this in the world of experience. I wonder how many readers find themselves in a similar position?

If you look at the Agile web space you’ll find that the emphasis is on ‘engineering best practice’ and tasks, rather than team processes.  Many project managers, too – are used to old-school leadership where they are more comfortable with control and the power that goes with it. So for Agile IT teams to become high-performing it’s essential that, right from day 1, time is spent in helping the team to initiate the process of adaptive learning and this requires a focus on behavioral skills.

Rather than let agile teams try to reach high-performance by trial and error it seems to me that the first thing to do is for everyone to understand the behavioral characteristics of their team members. One of the important features of this is measuring individual work preferences and harnessing these to the tasks that need to be undertaken.

To help agile teams prepare for the road to high-performance Bright Green Projects has  teamed up with the Team Management Systems organization to provide a free 8-page assessment of what you think about your current (or future) agile team. We think it’s really valuable, I hope you think so too.

Have a go at the Agile Team Performance Quiz.