Most of you know that I am not a huge fan of labeling my projects as waterfall, agile, or any other approach. Maybe it is the project manager in me or years I spent embedded in a Sales & Marketing business unit, but I am always aware of the expectations set by the labels and words we choose. However, if you are asking me to pick one ‘type’ that I am, then it would lean towards the waterfall approach. Let me back up for a second…most of the projects I have managed have been in very large, complex environments. They have spanned every function of the organization, every tolerance/maturity level with regards to project management, typically a dozen or more countries, and several initiatives (infrastructure, operations processes, marketing collateral, corp comms, legal/contracts, procurement/RFx exercises, etc)…some categorize these efforts as programs (i.e. – converting a global business unit from a cost center to a productized, profit center). With that said, I have often had an IT Project Manager on my team running the agile portion…software dev aspects.
Here at my current assignment, I have taken an opportunity to tackle a totally different environment. This company provides eProcurement software solutions to their clients and I am an implementation manager (project manager). I have 3 teams consisting of a Solution Architect, 2 Developers, and a QA resource and they each design & implement solutions for approximately 4-5 clients. Yes, 15 clients means A LOT of meeting for me! Here comes the big change…100% software dev focus, 12-16 week projects, and in an Agile environment. Very different from the 6 month-1 year projects/programs prior. I am close to 2 months in and have recognized a few things about Agile that every newbie should realize, so I thought I would share 3 of them with other Agile newbies…
- Meeting Purpose – Agile has stand-ups, grooming, planning, and retrospectives….ugggh! When you come from the waterfall space and shift to this environment, the sticker shock of meetings can be overwhelming. Especially when you have 3 teams and +/-15 clients. The key thing to remember is that every meeting has a specific purpose and you MUST stick to that purpose. When I say purpose, I don’t mean an agenda and goal/decision to made as in most corporate meetings. Rather, each meeting has a function/type/category…planning is for distributing work, grooming is for setting story points, retrospectives are for process improvement, etc. When I joined, every meeting seemed like open discussion about priorities, process improvements, etc. I had to quickly get the team to focus on the purpose of each meeting.
- Agile requires rhythm – This branches off from the point above. Each meeting has a purpose and feeds the other meetings. You need to trust the process/flow, get into it, and do not deviate! Kind of anti-agile I know, but when I speak of rigidity I mean around the process and various meetings. A stand-up may not make or break you, but if you start shifting around your planning or grooming meetings then you will see a domino effect. In waterfall, you could call a weekly on Wednesdays and if folks needed to push to the next Monday then you could make it work. Agile isn’t as forgiving in that sense. This may be because our teams are managing a number of clients in very short iteration periods, so I certainly welcome some feedback on this one.
- Roles & Responsibilities – Agile empowers the team, the doers, your developers. I heard one developer tell me…”What is this Agile stuff? Can’t you just tell me how you want it?” and another manager said “What do you mean we ask the developers the best way to do it? Why don’t we tell them this is what the customer wants? I don’t know if I trust our guys to do that.” Agile asks the client what is the business process? What problem are you trying to solve? Your developers know the capabilities of the system, they know the hooks, and they know the effort. If your team can’t or won’t then get new developers who are willing to learn a system, be creative, and add value. Your developers can come back with a solution that should meet the customer need and also is most efficient/friendly for your systems. Project Managers do not tell the team what to do, rather ask what is the recommendation to solve for that customer experience…AND how can I help? The Project is a team advocate and protector, making sure management is pushing down mandates or customers are submitting blue-sky requests. My most used statement in the past 2 months has been “Can you tell me more about that? I would like to know the current business process in-place. I can then take it back to my team and work through some recommendations that merge our capabilities with your needs.” During many of these meetings, I keep my mouth shut. Only when it comes down to clarification of the user story or a competing priority does the team look to me as the PM.
As I become more engulfed in the ways of Agile I will continue to share my experiences, frustrations, questions, and ah ha moments. I welcome any and all feedback from the CSMs of the world, as well as thoughts from other newbies.