I came across various companies – small ones and big ones – and a good indicator for a company’s agile maturity is the agenda of the regular team meetings. Usually you sit in these meetings and ask yourself what is this all about? The agenda is most of the time thin. Your line manager offers you some general information, some news about the latest deployments and team achievements. Seldom there is news that you haven’t already been communicated by other information channels. A highlight may be somebody presenting some key findings of his current project or research. At the end there will be some show and tell session for the team members where the usual suspects allot most of the speaking time.
Wouldn’t the team meeting be a perfect place to address stuff like improving everything, aligning constraints, growing structure, empower the teams, developing competencies and maturing personality? Inspired by Jurgen Appelo’s Management 3.0, Sam Carpenter’s Work the System and Michael E. Gerber’s E-Myth Revisited I will present you a practical and operational approach on how to easily and sustainably implement continuous improvement for your small to midsize business around a simple old fashioned team meeting. Even larger organizations could adopt the procedure if scaled up accordingly.
There is still a big gap between agile lead projects and
managerial practice in projects. A lot of companies lack the ability to scale
agile principles from their projects into day to day business. Not that I am an
evangelist of agile where I still see some shortcomings that have already been
addressed by notable experts but I really like the agile approach that solves
some of the most pressing issues in project management and software engineering.
Therefore I really like Jurgen Appelo’s approach applying agile principles to
management and entrepreneurship. Management 3.0 identifies six areas in which
management shall be active to create a hyper-productive work environment. The
areas are: Energize People, Empower Teams, Align Constraints, Develop
Competence, Grow Structure and Improve Everything. Along these dimension a
leader acts supportive and encourages the team to reach new peaks.
By chance I came across the Work the System approach established by Sam Carpenter. A simple and handsome approach for moving things forward in a company based on Strategy, Principles and Procedures.
Both approaches are practical. By bringing these approaches together I guess there is a considerable potential to further propel company development in an intuitive natural way that might be appealing to your stakeholders. So let’s delve into the details.
In Sam Carpenter’s book the approach is outlined in detail and you can start with your “Work the System” instance right away. “Management 3.0” doesn’t go very much into implementation details. Therefore we invested some time in finding an approach that limits administrative overhead to a bare minimum still guiding you in a structured manner towards the goals of the six Management 3.0 dimensions.
First define your Strategic Objectives and Principles based on Sam Carpenter’s ideas. In our case we developed our Strategic Objectives in a management workshop. We referred here heavily to “Work the System” and adopted the concept from there. In a subsequent company workshop we derived our Principles from the Strategic Objectives. The Strategic Objectives together with the Principles is our reference for decision making in our day to day business life. The approach further introduces the concept of Procedures/Work Instructions making it a trinity of Strategy, Principles and Procedures. These Procedures thoroughly document recurring tasks guiding people to do their work in a standardized and optimized manner. It is key that these Procedures are kept up to date and accurate to be of value for the company.
Our Strategic Objectives, the Principles and the Procedures shall be available for all employees. To keep this simple we just established a separate branch on the top level of our company Wiki.
In companies there is always a need to improve things, change outdated Procedures, and manage lifecycle issues and manage the unexpected be it by iterating through the problem domain step by step, anticipate future challenges or simply adapt to new state of affairs. The less managed and documented a company or a unit is the less transparent these needs are and recurring tasks are not documented and will be done in varying quality and higher efforts. You will find the company needs scattered to the four winds in various lists and concentrated in the heads of a limited number of key players.
Figure 1 Company Backlog Sample
We haven’t yet established a way to sustainably manage the backlog
and our Procedures. This is where agile principles come at hand to integrate
those into our team context.
To address this we need a company/unit backlog where the whole stuff is externalized becoming more transparent to everyone. The Procedures then persist the results of the issues/stories worked down in the sprints.
When company needs, issues and problems are transparent staff can tackle it in a structured way. In our case we introduced our company backlog simply in Wiki on the same level as the “Work the System” Strategy, Principles and Procedures. Above you see a sample company backlog.
In order to manage the company improvement backlog and our
Procedures we needed some recurring meeting to go through the various items for
prioritization, scheduling and Procedure management. The team meeting therefore
was transformed into a sprint retrospective and an iteration planning meeting. The
employees were encouraged to add, stories, issues, ideas and improvement
proposals to the company backlog in Wiki. In the first team meeting we went
through the backlog and added additional stuff that came up and made a
prioritization session. The most important and urgent tasks were then added to
the upcoming iteration with a simple effort estimation. We then asked in the
meeting for volunteers to implement the stories and resolve the scheduled
company issues until the next team meeting.
In the following team meeting the responsible people showed their achievements to the whole team in the retrospective. After having given credit for these achievements to the volunteers we went into the backlog again and started over with the prioritization session.
It is possible that an entry of the sprint backlog cannot be tackled in one iteration. In this case we either slice and dice it into several backlog items and digest it one per iteration or even better we kick of an internal project that deals with the issue as an own project. In this case the “Team Meeting” is the Product Owner. The responsible team then reports on a regular basis in the team meeting the projects progress. Should you have to deal with many of such projects you will have to restructure your agenda.
In order to keep this thing going one need some rules. Here comes into play what we have learnt from “Work the System” to document our recurring Procedures and let everybody participate in it. The Procedures in the “Work the System” approach are fairly simple (see the Team Meeting Procedure Sample below) with a minimum of editorial constraints. You have some header information, the purpose of the Procedure and the reference to the Procedures guiding Strategic Objectives and Principles. The main part is a step by step guide of the Procedure (if you like you can depict it with a Business Process Model or a UML Activity Diagram or any other suitable model). It is obvious based on the “Work the System” philosophy that the agenda of our team meeting is now itself a Procedure detailing the steps of the team meeting in a sequence starting with the retrospective, following the company backlog check, the reprioritization session and the vote for the next stories to make it into the next iteration including the effort estimate. Furthermore, this Procedure outlines how to handle new/updated Procedures. The Procedure shall be self-explanatory and detailed so that every employee is empowered taking the meeting chair.
Well done so far. Now let’s close the circle and tighten the whole agenda by adding the Procedures management to our team meeting. As aforementioned the team meeting itself is documented as a Procedure. After some company iterations there will be quite a number of Procedures accumulated documenting our results. These Procedures are important for our day to day business and need to be managed and kept up to date. People need to know at least the ones that are relevant for his/her job to be done. Therefore we decided to include the Procedures management into the team meeting as well.
After having defined the iteration until the next team meeting we look at updated and newly created Procedures. In order to facilitate this we have written some SQL queries that get all updated and newly created Procedures from the Wiki database. The result set of the SQL query returns all updated and newly created Procedures since the last team meeting including the employee responsible for its changes. Everybody having made the listed changes will inform the team shortly what has been changed and what the consequences are for each one.
Figure 2 Team Meeting Sample Procedure
As we go through the changed and newly created Procedures not seldom there is a vivid discussion being kicked off that leads to additional changes and the need for new Procedures. Those will then make it for the backlog. Should the change or the creation of the Procedure be urgent and highly important we sometimes open the sprint again for a new story with the newly to be created/to be updated Procedure. Usually the effort is limited so the sprint needs no further replanning.
Figure 3 Schematic overview of the Process
The agile manifesto doesn’t emphasize on documentation.
While applying agile principles on a managerial point of view not dealing with
Software as the primary work product we have to define what the work products
of our agile continuous improvement initiative are. Sure there is also code or
a new tool that can come out of a story that has been worked off in a company sprint
but usually we deal with new or updated company configurations that are defined
in a process like fashion documenting how to interact with our environment in a
consistent way. Such a configuration also can stipulate on how to use a
specific program/tool in the company context.
Therefore our primary work products are documented Procedures. Those Procedures ensure a stable and reliable functioning of our company. Although those Procedures are kept actual they are not the primary impetus for further development/change of the company. In fact they provide us with operational stability that is important for successfully run our business and satisfying our customers in a steady way.
To further continuously develop the company the company backlog is an important cornerstone. Although it promotes a more or less linear improvement process we need according to Management 3.0 also from time to time more dramatic changes. To rephrase it using an analogy from biology I would attribute the backlog management as gradualistic while the dramatic changes are punctualistic by nature. Usually the more dramatic changes come from an external force or due to a change in the Strategic Objectives of the company. Also a change in our Principles can lead to considerable rebuilding of the company. Such changes can rarely be anticipated but will then again fall back to our company framework with and Procedure management. With this company framework at hand not only some illustrious key people deal with the issues but you can tap into the creativity pool of your whole team. Having these means at hand the organization becomes more stable and can absorb also heavy changes much better and the recovery phase will be much shorter.
Now we come to the finale of our team meeting consisting of
two agenda items:
- Do the round: Each employee can give feedback in a traditional way. What has been achieved, what are the next goals? Any issues he/she needs support from team members/management.
- Elect the next host for the upcoming team meeting: From a shared responsibility perspective it is good practice to give your team members the opportunity to host the meeting. Therefore we ask the round for individuals willing to host the next team meeting. Next to improving shared responsibility it gives team members the opportunity to practice their presentation/moderation skills.
When you start to add procedures to Wiki you should define an own name space. This makes it easy to navigate through your company structures. Additionally your life will be easier when you set up a naming convention something like: “My Simple First *Procedure*”. You then also can do quick text searches and you will find your Procedures even if something with your namespace is not accurate.
Here is a simple SQL statement that runs against your Wiki
database returns all updated/created Procedures over a defined period of time.
Prior of using it check whether your Wiki version supports the same table names. According to your infrastructure you can export the result set directly to media Wiki format. The changed/new Procedure is then directly available via link (concat statement), which makes it easy in the meeting to navigate to the corresponding Procedures.
Over time the number of procedures will increase. To keep them easy accessible we have implemented a query in a top level page where all procedures are listed and linked. With good meta data tagging will be able to further order it based on topics or other ordering criteria that serve your purposes. Check in Media Wiki which plugin suits you best: Media Wiki External Data.
select p.page_id, concat('[[',p.page_title,']]'), u.user_name FROM mw_page p, mw_revision r, mw_user u WHERE
p.page_id = r.rev_page and
r.rev_user = u.user_id and
p.page_title like '%*Procedure*%' and
(SELECT MAX( rev_timestamp ) FROM mw_revision where rev_page = p.page_id) = r.rev_timestamp and
p.page_id = r.rev_page and
r.rev_timestamp > DATE_ADD(CURDATE(), INTERVAL -31 DAY)
Table 1 SQL Statement for querying Wiki
The meeting organizer is responsible for the minutes. We do
this as well in Wiki. It is always refreshing when you see after a few months
what you have achieved.
The meeting preparation includes the presentation of the updated/created Procedures from the SQL Wiki query (see SQL Statements). There are also plugins with which you can automate this. By the way - this is already part of our backlog hence with lower priority;-). To make your Procedures even better available to your employees add a Wiki-Overview Procedure Page. The more Procedures you will have the more important will the structuring become. Start using proper metadate so you can write SQL that can reflect the structuring.
In order to keep people interested and happy you should change the rules from time to time (see Michael E. Gerbers E-Myth Revisited). There is a lot you can do: Add some extra contest, kick-off a cool team project, define some learning goals, have a coding contest, switch roles and responsibilities and more…
· Cultural change is slow.
· Celebrate small success.
· Share responsibility - raising the self-worth and esteem as people can contribute to the company in a transparent way.
· An open agile culture is slowly being established over time.
· Method is open, debatable and adaptable – it is difficult for fundamentalism to thrive in an open community.
· No tooling overhead – keep it simple and stupid – and operate it with finesse.
· Company backlog gives any time a good picture where the company shortcomings are and where we stand. When your company grows add additional backlogs for additional departments like marketing, accounting and more.
· Works against the company blind spots.
To close the circle – there are ways to turn dull team meetings into a super productive host of boosting your company to the next level. Sometimes change doesn’t even hurt - especially when you are motivated and initiate the change as a whole team.
©ITpearls AG, Gregor Gisler-Merz
Carpenter, Sam 2009, 'Work the System' The Simple Mechanics
of Making More and Working Less, Greenleaf Book Group Press Austin, Texas.
Work the system
Gerber, Michael E 1995, ‘The E-Myth Revisited’ Why Most
Small Businesses Don’t Work and What to Do About IT, Harper-Collins Books, New
Michael E. Gerbers Site
Appelo, Jurgen 2011, ‘Management 3.0’ Leading Agile
Developers, Developing Agile Leaders, Pearson Education Inc., Boston MA
View Gregor Gisler-Merz's profile