Google+

3 Things to Know About Agile

11

March 21, 2012 by rkelly976

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…

  1. 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. 
  2. 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.
  3. 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.

About these ads

11 thoughts on “3 Things to Know About Agile

  1. I take pleasure in, lead to I discovered exactly what I was having a look for. You’ve ended my four day lengthy hunt! God Bless you man. Have a nice day. Bye

  2. I’m going to just add a few quick bullets. I think Stuart did a good job of nailing down Scrum.

    For TFS:

    1. Who is responsible to prepare FS, MOM and test scripts?
    > Please define FS and MOM to avoid misunderstanding
    > Acceptance tests are usually defined by those who will consume the deliverable
    > Unit test scripts can be defined by developers or other team members
    > Other test scripts can be defined by QA or other team members
    2. What if team member unable to contribute in the meeting? Is it a must to have a SA in the project?
    > These are two unrelated questions.
    > First: Which meeting are you referring to?
    > Second: if you are leveraging Scrum, yes. If you are not leveraging Scrum, no.
    3. Is it suitable for turnkey project?
    > Please define turnkey project
    4. Why can’t scrum master to be the product owner?
    > The PO represents the business. Will prioritize the work to reach business goals.
    > The SA represents the team and is a servant leader.
    > Can’t be the same person due to a conflict of interest
    5. It’s important for the team member to directly liaise with client / end-user, what if the team is not comfortable to perform? (For e.g. too many high profile stakeholders involved like CEO, General managers, & Senior managers).
    > That’s what the Product Owner is for. They will speak on behalf of those in more strategic positions.
    6. What kind of reports need to be prepared by Scrum Master?
    > None. In Scrum, the team maintains the team board. That’s your official reporting mechanism.
    7. What is the optimum time-limit for a meeting? What if there are too much of details need to be discussed?
    > There is no optimum time limit on a meeting. It depends on team size and work complexity, among other things.

    All good questions.
    Did I miss any?

  3. […] Posts Top 10 Issues for Project Managers3 Things to Know About AgileA Project Manager's Guide to Negotiation SuccessLeadership Lessons from an Illiterate turned […]

  4. Paul Naybour says:

    Hi

    I do need some help with this, I have a client in the rail infrastructure business who wants to apply agile thinking to the building of major rail projects. They are multi-million pound projects to build new stations and rail upgrades. Classic waterfall. How to adapt the agile thinking to these project is my next challenge. Saving it for the summer break while we enjoy the Olympics in London.

  5. TFS says:

    anyone has adopted both Agile and Waterfall model to deliver a project?

    I have following questions for Agile practitioners:
    1. Who is responsible to prepare FS, MOM and test scripts?
    2. What if team member unable to contribute in the meeting? Is it a must to have a SA in the project?
    3. Is it suitable for turnkey project?
    4. Why can’t scrum master to be the product owner?
    5. It’s important for the team member to directly liaise with client / end-user, what if the team is not comfortable to perform? (For e.g. too many high profile stakeholders involved like CEO, General managers, & Senior managers).
    6. What kind of reports need to be prepared by Scrum Master?
    7. What is the optimum time-limit for a meeting? What if there are too much of details need to be discussed?

    Appreciate someone can answer by humble questions posted, thanks.

  6. califgirl232 says:

    Wow, great discussion here. Robert; I like your perspective you’ve provided for newbies; tools are tools. In any organization it should be the right fit of tools, for the right project for the right customer. Robert’s experience does share with us that change leadership and soft skills are essential from the business and the teams required to use Agile and Scrum methodologies.

  7. rkelly976 says:

    @Stuart – Wow! Your comment is longer than my actual post! LOL I am honored that you took such time and effort to help coach the audience along. My post was not intended to accomplish such a goal, rather introduce some of the higher-level things newbies need to understand.

    I encourage my subsribers and visitors to fully read your post/comment, as there is some really good content. If they are in the APAC region, they could also check out Odd-e’s services…http://odd-e.com/#pageContactUs

    On the flip side…getting stuck on symantics will be the continued demize of this profession/discipline. Industry average hangs project success around 50% and the definition of that can be debated, but in the end I am not conncerned so much with titles…call me an intern, scrum master, or guy in the corner. Additionally, if my team members (resources) are offended that I refered to them as a resource in a high-level blog, then I have done a very poor job of making them feel a valued member of the team. I guess what I am saying is that, the PM space is getting very stuffy with terms, acronyms, and methodologies when they are just tools and guidelines. That is really all this post was meant to deliver.

    Thanks again Stuart!

  8. rkelly976 says:

    @Vin thank you so much for your comment. I agree, one of the biggest challenges I have seen is the mindset change required to move into a agile environment.

  9. Stuart Turner says:

    Hi Kelly

    From what you describe, I assume you’re trying to use the Scrum framework?

    You mention meeting purpose and you’re correct, each meeting in Scrum does have a purpose. Like many, though, you’ve mistaken the activity in each meeting to be its purpose. This happens when people see others doing something and just copy it. They don’t investigate further and ask questions as to WHY they’re doing it. I meet so many people who tell me they’re ‘agile’ or using Scrum only to discover, they have a standup meeting every day and have to answer three questions. Sometimes that’s as close to following Scrum as they get. True understanding is lost and the purpose remains unfulfilled.

    I think referring to people as QA resources could be taken quite offensively, although you probably don’t mean it that way. Calling them resources also sounds as though you believe you can interchange one QA resource (or other skilled role) for another. Partitioning people by their main skill set is how organizations try to manage staff. People are educated and skillful, and what’s more, they can even learn new skills in multiple different areas! Scrum recognizes this exceptional ability (ignored and restrained by most organization) and makes no specific role for them and just says they form the team. The team is cross-functional, stable, commonly focused and self organizing, where responsibility is shared and where the common goal is to deliver a good return on investment for the product owner and to do it sustainably.

    Meeting Purpose:
    The purpose of grooming is NOT setting story points!
    The purpose of planning is NOT for distributing work!
    The purpose of retrospectives is not just for process improvement!
    Yes, Scrum has a rhythm, but not just for its own sake.

    I’m not really sure what role you’re taking. It seems you’re still calling yourself a project manager when there is no such role in Scrum. Some of what you say indicates you’re acting as a product owner but you would need to have ownership of the budget to perform that role. Some of what you say indicates you’re acting as Scrum Master but you’re responsible for other things that conflict and prevent you being able to perform that role.

    Your Roles & Responsibilities section is pretty good but then you ruin it by referring to a project manager. I don’t understand what this means: “The Project is a team advocate and protector, making sure management is pushing down mandates or customers are submitting blue-sky requests.”

    Be careful of assuming anyone with a CSM has a deep understanding of Scrum. Someone who attending a two day course and completed a test is given the title CSM. They need have no actual experience and often have very confused ideas about Scrum. From your post, I would say you are currently one of those people.

    So what is Scrum or agile and what are the purposes?

    Grooming is where estimating of backlog items takes place. The PURPOSE is to create a shared understanding of the problems the users and other stakeholders are trying to overcome. That’s why this meeting should involve users and other stakeholders, so they can discuss and clarify directly with the team. They should not go through a solutions architect, BA or PM! It should be directly with the team. Assumptions can be discussed and be prevented from leading development in the wrong direction, causing unnecessary waste.

    If grooming is being performed sufficiently well, planning part 1 is just the team selecting enough items from the backlog to take to planning part 2.

    Planning part two is where the team discusses the selected items in more detail and breaks them into tasks. The PURPOSE is to create a shared understanding of what they plan to do in order to complete the item. For this, they will require their agreed definition of what ‘done’ means. They should also have improvement tasks from the previous retrospective to perform in this sprint. Tasks are NOT allocated at this time but rather taken up by the team throughout the sprint. When the team has created all the tasks they can identify for an item, they then use estimation to further discuss what will be required. Different estimates are welcomed as they often cause discussion from all viewpoints and this leads to a better understanding of what is required. This helps prevent ‘who talks loudest, wins’ though many teams still make decisions that way! Those who don’t talk as much often have valuable insights and individual estimating gives them a chance to give their viewpoint. Remember this is estimating to create understanding. Don’t spend time and effort to be more accurate than is useful. Estimates, even at this level of detail, often turn out to be quite wrong. With the estimates, the team is able to decide how many items they can complete and give a commitment to the product owner.

    The team work collaboratively on the highest priority item’s tasks until the item is ‘done’ and then seek feedback from the product owner on whether she agrees the item is ‘done’. Do not wait until the review meeting before seeking feedback! The team then move to the next item’s tasks and so on.

    The review meeting is where some of the stakeholders and the product owner see and use the latest product increment and give their feedback to the team. It also gives them the opportunity to redirect the product development by adding, changing and even removing items from the product backlog. The product backlog is a living list reflecting the current vision!

    Retrospectives are for the team to reflect back on the sprint and to express appreciations to teammates. They asses what went well and what didn’t, what they’d like to keep doing, stop doing or experiment with. They then look to the future and identify which areas they want to focus on improving and create S.M.A.R.T. actions for the next iteration to move them towards that goal.

    Scrum time-boxes the sprint because it’s important to get full cycle feedback as soon as possible. With this feedback, you can learn, improve and redirect each iteration. Two week sprints are very common. One week is even better and four weeks is too long, but it really depends on your context, not on your current capability. The meetings are time-boxed relative to the length of the sprint so you don’t waste time. They give you a boundary within which to work and make decisions. If you fix the scope, it means you either deliver all or nothing whereas fixing time means you deliver what you have ‘done’ so far. Whether it’s what you predicted is not important. What you deliver is the reality. Delivering 90% of the highest value items so it they can be used and you can get feedback is better than delaying to deliver the last 10% which may not be worthwhile or even desired anymore.

    Using Scrum requires discipline; much more than when trying to use predictive project management. It requires people to give up certain responsibilities they performed in previous roles (project manager no longer exists because the responsibility for project manageMENT is shared between the team and the product owner). The team manages themselves and will require assistance and support from others in the organization when they ask for it. Without these things they will not take on the responsibility, not improve their processes and practices and they will not be able to respond more quickly to change with little additional cost. They will not become more agile!

    I hope this helps explain the underlying purpose of the meetings in Scrum and of Scrum itself. I also hope it allows you to improve your ability to deliver products empirically rather than believing you can predict much of it at the beginning and then try to follow your predictions.

    Stuart

  10. Vin D'Amico says:

    You raise some good issues. Every software development approach has its rules. Waterfall is heavy on analysis and documentation. Agile approaches are heavy on collaboration and sharing. Some behaviors have to be enforced otherwise you end up with chaos. That’s why cultural change is such an important part of using agile development. It’s not simply another way of writing software. It’s a whole new mindset around how to solve business problems via software.

    Thanks for sharing your experiences.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 5,750 other followers

Runner-Up: Best New Blog

Follow

Get every new post delivered to your Inbox.

Join 5,750 other followers

%d bloggers like this: