When invoicing on an Agile project, consultancies are often asked to provide granular reporting of daily tasks. This allows the client to see an exact cost breakdown of each feature developed – providing a mechanism for reconciling project delivery costs.
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.
Agile Consulting by .
Introducing Agile concepts to a business environment plagued by traditional approaches (waterfall) can be a political nightmare. Here are a few short strategies to help alleviate the pain.
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.
As a partner in a consulting firm for many years, who has just moved to Bright Green, I am all too familiar with the eternal struggle to balance the supply and demand of resources. Life seemed to swing, somewhat rapidly, between a frantic search for clients to sell work to, and a frantic search for resources to deliver that work. The brief moments of balance between supply and demand were rare times to be cherished while they lasted.
As demand rebounds in many markets around the world, the frantic search for resources is ramping up, and the order of the day frm many clients is resources with skills in Agile. Long the mainstay of independant software development teams and small start ups, the Agile buzzword has reached the mainstream ears of business execs who are being asked – and in turn asking their consultants – how can my business become more agile?
For consultants, the opportunity that presents itself when this question arises is greater than it may initally appear. The tempting reaction is to try and stitch up a consulting contract, dive into delivering value for the client, and pocket the cash. The real opportunity on the table however, is to transition away from the sell-deliver-signoff cycle of discreet consulting engagements, to a client model that is based on a never ending, and uninterupted stream of of work.
Sounds too good to be true? The answer lies in continuous nature of an agile engagment. In becoming more agile, a business is constantly identifying ways to improve, prioritizing those improvments and taking them to market in the smallest amount of time possible. Consulting expertise is often a valuable and necessary ingredient to making this happen, and an Agile model that turns employees into Agile Agents who load new business requirements – as they appear – into a backlog that their consulting partner will immediately action, is what is needed for success.
Is this just a selfish way to sell more over priced agile consultancy work and lock out competitors? No. The reality is that a continuous engagement model is not only good for you as a consultant, it is good for your clients who see faster time to market, and greater visibilty in cost and benefit. Those are the ingredients for a Very Long Engagement.
Agile Consulting by .
The Naked Project Management Method
We’ve seen Consultants so good, that the client is afraid to do anything without the approval of the consultants, and other relationships so poor, that status meeting regularly end in tears.
The aim of the Naked Project Management Method is to strip off your consultants’ fancy suits, wheelie suit cases and heavy documentation and work together as a transparent team.
Consulting 101. If you can’t dazzle them with brilliance, baffle them with bullshit.
Consultants have a bad habit of producing loads of documents, strategy papers, diagrams and holding loads of long meetings. These are all important and crucial to the success of many projects, however, there comes a point when the project needs to start, hard decisions need to be made and build needs to begin.
Productivity Tip – Strip your consultants bare and explain to them that you value documentation and meetings, however, you’re only really going to measure progress by working solutions delivered at regular intervals – ideally 2-4 weeks.
Consulting 102. Everything is pretty much on track.
Another bad habit of the consultant is to always tell your client that things are “going to plan”. This fascade is often kept up as long as possible. The sad thing is, that often this is left so late that not much can be done about it once the news is delivered
Status Tip – Ensure your Agile Consultants deliver real, working solutions every few weeks. This way you’ll always know the true status of the project. If you find out early, you can do something about it. Including getting a new team of consultants!
Consulting 103. Land and Expand
Get someone on the ground with the client, then bring in as many new consultants as possible.
Sometimes this is a saviour and as the consultancy has access to a global pool of talented people, this alone can save the project. The negative is that it is often not clear who is doing what, or even how many consultants are on site until the bill comes each month!
Teamwork Tip – Make sure that all of your teams are no larger than 7 or 8 and that everyone is clear who is doing what in each team. Make sure all the teams are talking to each other.
From time to time, we like to review the other Agile Project Management Software out there on the market for Scrum and Kanban. We built Bright Green to support our own Agile Methodology, so they of course are our favorites. However, don’t just take our word for it, check out some of the comparisons below and make up your own minds.
Objective: Gain a better understanding of the advantages and disadvantages of various Agile tools
Tools Compared: Bright Green, Rational Team Concert, Rally, VersionOne
|
EASE OF USE |
|
|
|
|
|
|
Bright Green |
RTC |
Rally |
V1 |
|
Intuitive user interface
|
x
|
x
|
x
|
x
|
|
Average learning curve/ramp-up time is less than a day
|
x
|
x
|
x
|
x
|
|
Drag-and-drop capabilities across different views
|
x
|
x
|
x
|
x
|
|
Bulk edit capabilities across different views
|
x
|
x
|
x
|
x
|
|
WYSIWYG Printing |
x
|
x
|
x
|
|
|
Support direct web link to an individual story/issue which can then be emailed to a user or linked to from another web site. |
x |
x |
|
|
|
CUSTOMIZATION |
|
|
|
|
|
Custom fields types include Boolean, single-line text, multi-line text, checkbox, number, date/time. |
x |
x |
|
|
|
Custom tabs to view other Web applications |
x |
x |
x |
|
|
Bi-directional traceability of life cycle artifacts |
x |
x |
x |
|
|
Change tracking of all changes on all items |
x |
x |
x |
|
|
Flexible filtering and Column Sorting |
x |
x |
x |
x |
|
MULTI TEAM SUPPORT |
|
|
|
|
|
Ability to synchronize release and sprints across teams
|
x |
x |
x |
x |
|
Support multiple teams working on a single release |
x |
x |
x |
x |
|
Manages concurrent releases |
x |
x |
x |
x |
|
Sprint status across multiple projects |
x |
x |
x |
x |
|
SOLUTION MGMT |
|
|
|
|
|
Create and Maintain Solution Backlog |
x |
x |
x |
x |
|
Import User Stories from other sources |
x |
x |
x |
x |
|
Decompose Epics and User Stories into smaller Epics/User Stories |
x |
x |
x |
x |
|
Visually depict Hierarchy of Epic/User Stories |
x |
x |
x |
x |
|
Estimate User Stories using historical estimating data |
x |
|
|
|
|
Assign/Reassign User Stories to Releases – drag and drop multiples at once from the Solution Backlog |
x |
x |
|
|
|
A Release can span multiple teams |
x |
x |
x |
x |
|
Create Task ordering under each story |
x |
x |
x |
|
|
REPORTING |
|
|
|
|
|
Dashboards |
x |
x |
x |
x |
|
Sprint/Release Burndown |
x |
x |
x |
x |
|
Issue Management Reports |
x |
|
|
|
|
CSV exports |
x |
|
x |
x |
agile tool reviews by .
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 project management 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 project management 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.