Part #2: Agile meetings run by an agile chairperson

All of us have attended many meetings during our careers, some good and some not so good. The idea of the sprint meeting: where hands on stakeholders (product owner(s) and technical team) meet for 10 to 15 minutes each day, stand up around a white board and answer 3 basic questions:

#1 What did you do yesterday (reporting back on the commitment you made the day before),
#2 What are you planning to do today (today’s commitment) and
#3 Is there anything stopping you fulfilling your commitment.
Ranks high in my book as a good way to run a meeting to get an understanding of the status of a project, it's: concise, precise and efficient. These meetings are co-ordinated and arranged by the scrummaster (Product or Project Manager).

Sprint meetings which are an essential part of the agile scrum framework.

Sprint meetings are not too different from many typical management meetings that we attend – ironically, these meetings are not conducted in an agile way or form part of an agile framework. These meetings have very firm agendas where each item is time-boxed. It's the job of the chairperson to firmly keep the meeting on track – the final agenda item is traditionally 'any-other-business' (AOB ) which is usually time-boxed at round 5% to 10% of the total meeting time. Some chairpersons will do a 'round robin' in place of AOB – giving each person time to raise any issues they may have (this too is usually time-boxed to 5% to 10%) not enough time to tackle any real issues of concern.

It goes with out saying that the way you chair and organise a meeting depends a lot on the type of meeting, the aim and circumstances surrounding the meeting and the people who will be attending.

For regular team meetings I prefer the more flexible agile approach where the chairperson sets the agenda, gives plenty of opportunity for those attending to add agenda items, publishes the agenda before the meeting and then raises each agenda item in turn but allows the team to divert onto other topics (irrespective of whether the item is or is not on the agenda). The chairperson tactfully pulls it back on track if the discussion does not seem to be adding value to the team or department. Running a meeting in this fashion does take a bit longer (probably up to 25 - 35% longer) however the benefits outweigh the cost.

Another way to run an agile team meeting is to do away with a formal agenda. The chairperson (departmental or team leader) opens up and tells the team what their issues, concerns and achievements are. Then they open up the floor so that others can contributes and share their plans, concerns, achievements etc... I’ve been in teams where this method has been used and over time it has produced good results.

Team morale is kept high as people value agile meetings as a place where concerns can be raised, discussed and possible solutions and support given. This also has the added benefit in that the chairperson (departmental or team leader) gets to know what individual members of their team really think (people talk more freely when they are relaxed and not time boxed) and an understanding of the true concerns and issues that the department/team may be facing – as opposed to a polished presented one-liner that makes them look good.

I worked with one MD several years ago who calculated the cost (based on everybody's, hourly rate) of our weekly team meetings. OK it had the effect that we become more concise with our comments and therefore kept the meeting as short as possible. However the MD didn’t really know what was going on in the various departments in the company.

To get a better return on investment (ROI) out of meetings takes the initial investment of time, that will give you the scope to chair in an agile way. Agile meetings gives the team members time to talk freely – this gives you the ability to really get to the bottom of what is happening. To get concise to the point status of a project adopt a daily sprint meeting (10 to 15 minutes max) the combination of the two (sprint meetings every day and agile meeting every week or two) will help you run any team and or project in an effective way – insuring that you get the best of both worlds: timely reports and a grasp of the real concerns the department/team are facing - the ultimate result being a better ROI from your team.

See also Product Management Productivity Tip #3: Master Meetings

Read More

Part #1: Implementing an Agile Sales Framework

By their very nature sales people are agile in their approach to selling products and services. A good sales rep will intuitively carry out a quick inspection of the prospective customer’s situation, adapt themselves to make the customer feel at ease, and continue to inspect (by asking the appropriate questions) until they feel confident enough to present a solution to ease the customers business-pain. The problem occurs when the salesman becomes too agile by claiming to be able to solve a business pain to which they have no direct solution – or make a commitment to be able to deliver, a solution, with in a timescale that has not been agreed with the technology teams or Product Manager.

Sales teams need to also inspect the technology team’s capability of delivering bespoke or custom designed solutions – this should be done via the Product Manager.

To make a positive contribution to the agility of a company, sales need to operate within an agreed agile framework much in the same way as software development teams operate with in frameworks such as Scrum or DSDM.
A simple framework for the sales teams to operate in might look something like this:

• Only make commitments on products that are released and being shipped.
• If it does not do it out-of-the-box then do not make a commitment.
• Understand the iteration of the software department – know when sprints are starting and when functionality will be released – again the job of the Product manager to communicate this information to the appropriate stakeholders.
• Give feedback on requests for bespoke development, there may be synergy with other requests coming in from other sales teams with in the company.
• Product Managers compare request for bespoke work with agreed roadmap.

Most Product Manager and developers have experienced having to put everything on hold, change direction, divert from the strategic roadmap and deliver a new product or new functionality in order to secure a deal. This is fine – because agile software development is flexible enough to facilitate ad-hoc changes to meet the customer’s needs, however constant chopping and changing has to weighed up against the companies desire to produce functionality and products that has been defined on the product roadmap. I’ve always admired Chief Executives who have walked away from a deal in order to keep the technology teams focused on the current roadmap. I’ve experienced diverting from the product road map to secure medium size deals only to loose bigger deals later on because we did not have that much needed functionality. Worst still I turned up to an exhibition only to see that the competition were demonstrating the feature we had delayed implementing while ours was not yet mature enough to even begin alpha testing.

Technology teams and Product Managers can help shape an agile sales framework by:

• Being an example and demonstrate the benefits of using an agile framework
• Communicate the capabilities of the team (velocity) and let sales know that we can react quickly BUT it comes at a cost (i.e. diverting form the current work).
• Encourage regular and open dialog with the sales team to glean from them the problems their customers are facing - the solution just may be lingering in a developers or product mangers head.
• Update the product roadmap based on feedback and then feed this back, at the appropriate time, to the sales team(s).
• Accompany a sales man on at least one sales trip a year; this will help you understand the commercial pressures that the sales team are under – who knows it could lead to your career changing direction towards technical sales.

Sales teams play a vital part in any successful commercial operation. It is therefore vital for them to operate with in an agile framework in order to ensure that the company does not become a victim of its own success and to make a postive contribution to the agility of the organisations.

The combination of an ‘agile development frame work’ and a ‘sales agile framework’ is akin to a combination of "business sense and technical sense" – it’s just common sense.

Read More

Identifying Agile Organisations, Functions and Roles

There currently seems to be a strong move towards agile software development. Engineering teams and I.T. departments are adopting one agile method or another. However the conversion of software teams, to agile, does not naturally result in the other areas of a company adopting an agile method of working. The question is why should other areas adopt an agile approach to work? The answers is simple - because it is important to 91% of CEOs who are looking at how their company’s will develop over the next 5 years.

Some departments and functions could improve their performance by working in an agile way, while it may not be at all suitable for others. Some departments and functions (in some companies) do work in an agile way but we probably don’t recognise it. While it would be totally inappropriate for others to even consider adopting an agile way of working.

This article is an introduction to a 10 part series on how Product Managers and Engineering teams could influence various aspects of a company to help them identify and/or adopt an agile approach to working. It is also important for technical people to be aware of how other departments operate - many jobs, positions & functions: CEO, Managing Director, COO, Sales, Marketing, Product Management etc... in Hi-Tech companies are performed by people who have strong technical/engineering backgrounds.

The areas that will be covered are as follows:

1. Agile sales
2. The agile chairperson or meeting co-ordinator
3. Agile training
4. Agile customer support
5. Agile product marketing
6. Agile for everyone
7. Agile software testing
8. Agile management
9. Agile product manager
10. Agile research
    

Being an agile company means that you’re a competitive company – being competitive increases your chances of an increased return on investment (ROI ). An increase in ROI means more investment in technology, training and research and ultimately to greater job satisfaction. Hope you enjoy and contribute to the series.

Read More