Project Planning Without Knowing the Details

Agile Project Planning Techniques Overcome Fear of Unknown

We understand there is an overarching desire in project management to know a good amount of detail before project planning takes place. Traditionally, these details are constrained by Time, Scope, and Budget.  It has almost always been my experience that Time and Budget that are fixed.

If two of our three biggest constraints are fixed, then why are we so afraid of project planning? We fear the unknown. This fear of the unknown can range from intimidating to downright scary. The GSD Method of agile scrum offers several techniques to overcoming this fear that keeps us becoming better project planners and accurately predicting what and when we are going to deliver results.

Change the Fundamental Way You Plan Projects

In traditional waterfall project management, we typically get a six month to two year roadmap, and we build out a detailed work breakdown structure with hundreds to thousands of tasks (no joke, I have actually seen a project with 10,000 tasks to plan and track). Then, we go through weeks of scheduling those tasks with the core and extended project team, only to find that about two months into the project, the plan is irrelevant and out of date.

The first step to throw out the notion of traditional waterfall planning and begin thinking in terms of Epics instead of work breakdown structure. What is an Epic you ask?

Think in Terms of Epics

An Epic is a high level feature of a product or application. For purposes of this post, let’s say we want to develop an airline reservations application.

At the start of the project, the Scrum Master brings the Development Team together with the Product  Owner. The Product Owner lists the features (or groups of related functionality) that the customer needs the team to deliver to meet business deadlines. Each feature becomes an Epic.

A few example Epics of our airline reservations project include:

  • Customer Login
  • Customer Book Airline Reservation
  • Customer Search Airline Reservation
  • Customer Change Airline Reservation

Decompose the Epics into Components

Once the team identifies the list of Epics to be delivered as part of our project, it is time to break these Epics down into GSD Gold Components. A GSD Gold Component is a unique part of the feature set that can be delivered as standalone, independent functionality. For our object-oriented or UML friends, think of a GSD component as a use case.

We could decompose our Back to our Customer Book Airline Reservation Epic into the following Components:

  • Customer searches for available airline flights
  • Customer selects flights to book and creates an airline reservation
  • Customer pays for airline reservation
  • Customer searches previously booked reservations

When the team cannot think of any new Components for all Epics in the project, it is time to start thinking about the MVP (Minimal Viable Product) and scheduling release milestones.  

Define the MVP and Delivery Roadmap

The Product Owner and the Business Analyst (if you are lucky enough to have one on your scrum team) meet with your customers and identify the highest priority components that provide the most value and should be delivered first. If the team has 90 days to deliver a fully functioning airline reservations application, a full review of all the Epics and related decomposed Components should be reviewed and prioritized.

The following steps help identify the MVP:

  1. Group Components that should be delivered together (these definitely can reach across Epic feature sets)
  2. Prioritize Component groups for delivery and decide release dates
  3. Rework the Component groups until the team feels comfortable delivering by the release dates assigned to the team

Viola! We now have an agile release plan that, in the real  world, lines up against strategic roadmaps and that the team feels comfortable delivering.

Focus on Near-Term Deliverables

Agile is not an excuse for cowboy coding. Once you know the Epic features your team plans to deliver, have your architect or tech lead create a high level design or architecture roadmap for your application.

Now, it is time to start focusing on near-term deliverables. We’re not talking about breaking down every Component into a detailed plan, we’re talking about focusing on what we need to accomplish in the next 2-4 weeks or the next two 2-week Sprints. A Sprint is a time-boxed development cycle. Our Sprint preference is 2 weeks, as we believe this is optimum for most development teams.

To get ready for the team’s first Sprint, the Product Owner and Business Analyst further break down the highest priority Components into Stories. In agile scrum, Stories are the requirements and quality assurance acceptance criteria that make up what need be delivered.

You don’t have to write every Story for every Component, only those Stories that must be delivered in the next 2-4 weeks. How awesome is it that? The first two sprints set the pace or velocity of the project, give the team something to demo so the customer can validate their requirements, allow the team time to pivot if requirements change and ensure the team has the confidence to deliver on schedule.

For more information, check out:

Chapter 2 in our GSD Scrum Handbook: GSD Gold Project Planning 

Chapter 3 in our GSD Scrum Handbook: GSD Gold Story Writing

Happy planning,

April Shepherd

April Shepherd
AprilS@gsd.guru  503.307.9072

Contact Us read more

No Management Buy In For Agile? Then Earn It!

Getting Leadership to Buy Into Agile

I’m sure you’ve heard people say, “We tried agile scrum and it didn’t work.” This is mostly from their first-hand experiences of trying agile and failing or hearing others share their horror stories and they are terrified to try it themselves. Whenever I hear these words, I think to myself, “I bet they didn’t implement scrum correctly.”

Why Scrum Fails

In my experience, the misuse of scrum methods leads to management’s resistance to agile scrum. It all boils down to the fact that scrum fails when the Development Team operates independent of any corporate objectives and strategic milestones.

When Development Teams operate without strategic direction, agile becomes the team’s excuse to work on whatever they feel like working on. I’m amazed when I asked why teams function this way and I hear, “We are agile, we will figure it out as we go.”

I have seen developers build whatever they want whenever they want without: a scrum team, prioritized backlog, and groomed stories and time boxed development cycles or sprints. This way of functioning is known as cowboy coding. With cowboy coding, the developers get to work on fun stuff, challenging stuff, easy stuff, whatever, without any consideration or coordination with the business. Remember, true agile works hand-in-hand with the business.

Even in cases where there are Development Teams using true scrum best practices, I have seen teams still not take into consideration corporate milestones. When key business areas have dependencies on deliverables beyond the time box of the sprint, say 3 months down the road, I have heard the Development Team respond with, “We do not plan that far ahead; we only plan 2 weeks in advance.”

No wonder leaders can be very cynical about agile scrum!

Steps to Leadership Buy In

If you plan to transition to agile and you do not plan to accomplish the 4 steps outlined below, your efforts can result in another horror story.

The 4 Steps to Scrum Success:

  1. Ensure management and the Development Team have proper agile scrum training
  2. Define project milestones for proper project tracking
  3. Develop as an agile team
  4. Status report progress on regular basis

Leadership must understand agile scrum teams are functioning in accordance with standard practices. For this to happen, we recommend management attend high-level agile scrum training, so they understand how they may have to change their management style and expectations. In addition, every member on the scrum team should go through formal training to ensure everyone is on the same page as to how to operate as a fully functional agile team.

Once the leadership and the agile scrum team are formally trained, a coach should be brought in not only to guide the team through training, but to support and build the right behavior through the execution of their first 3 sprints.

Remember that agile is more than a process. It’s a mindset shift. That’s why we believe training and coaching after training are so important.

Leadership needs to feel confident that the team can deliver to business objectives and corporate milestones. “Figuring it out as you go” and “It will be done when it’s done” are not agile. They are excuses for not wanting to be accountable.

We have a way to guide Development Teams through the process of breaking down high level requirements and creating a release plan that lines up with the strategic roadmap. In Chapter 2 of the GSD Scrum Handbook, we talk about The GSD Gold Approach to Project Planning in detail. This can help you demonstrate to your leadership how agile scrum can and does support corporate objectives.

Every Development Team has a Product Owner that works hand-in-hand with the business. The Product Owner represents the business, captures requirements in the form of stories (or product functionality), prioritizes those stories into the backlog and then guides the team on what to work on each sprint. It is the Product Owner’s responsibility to ensure backlog items are reflecting the organization’s strategic roadmap from a functionality and timing perspective.

Another point of contention with leadership is visibility into how their Development Teams are tracking to completing their committed work. Throughout the sprint, Story Boards and Burndown charts provide visibility and traceability throughout the sprint cycles. Both of these tools should be available to all members of an organization at all times either in a tool or on a whiteboard. We talk about this in Chapter 6 of the GSD Scrum Handbook.

The agile Development Team must also be able to report project progress beyond the limits of the sprint. In Chapter 10 of the GSD Scrum Handbook, we explain how to accomplish this.

Once leadership has visibility through regular status reports and sprint transparency, they will begin to have confidence the Development Teams can deliver against their strategic roadmaps. Delivery to corporate objectives proves scrum works efficiently and effectively.

If you have any suggestions or comments from your own personal experiences, please post them below.

Want more details about how scrum can work for your organization?
We recommend you get your own copy of the GSD Scrum Handbook.

DSC_4880 (500x483)

April Shepherd

April Shepherd
AprilS@gsd.guru  503.307.9072

Contact Us read more

Transition Your Team from Waterfall to Agile Scrum

My First Agile Scrum Project

The first question traditional waterfall development managers ask when they are looking to transition to agile scrum is, “How do I make this happen?” I’m going to share my first transition from waterfall to agile scrum five years ago and, hopefully, this will help you with yours.

Background

I was a traditional waterfall project manager at a Fortune 500 international company. My team consisted of 2 developers, 2 quality engineers and 1 tech lead. The overall scope of the project was to procure and build the infrastructure from the ground up then to develop the following functionality: Email, Push, In-App and SMS.

Waterfall is OK for Architecture Buildout

We managed the procurement and buildout of the supporting architecture using the traditional waterfall approach, because there were simply too many dependencies on technologies and non-dedicated team members needing to do work outside of what would be an agile scrum team. We referred to this buildout period as Sprint Zero.

Begin the Transition from Waterfall to Agile

Sprint Zero

I obtained my Certified Scrum Master (CSM) certification and our team engaged an onsite scrum coach (similar to the services we offer at GSD) to train our entire team. Everyone on the team attended the training, including our new Product Owner.

Topics we learned included:

  • Defining Epics
  • Defining Sprint cycle
  • Story Writing
  • Backlog grooming
  • Estimating and assigning story points
  • Sprint Planning     
  • Daily Standups
  • Product Demos
  • Retrospectives
  • Reporting sprint velocity
  • Setting up and configuring tracking tool (JIRA)

Training sessions were spread over a few weeks to minimize disruption to the team and to allow them to complete their infrastructure buildout tasks. As a new scrum master, I worked closely with the team to ensure we were all aligned on how to implement agile scrum and how to be successful.  

Sprints 1 to 3

We decided to start with 2 week sprints as our coach advised this is optimum for most development teams. We have found 2 weeks to be the magic number with all our agile scrum teams. We also found this was a good amount  to analyze, develop, test, and document potentially deployable packages of code.

To ease the transition, our scrum coach attended all of our Story Writing, Backlog Grooming, Sprint Planning, Product Demo and Retrospective sessions during our first 3 sprints. Our scrum coach would be a silent observer in these sessions, but would interject if the team went off track or had questions about scrum.

This support gave our team, including our new Product Owner, confidence that we could fully function and deliver as a new agile scrum team. We wanted to demonstrate that we could quickly develop deployable code and show tangible work progress in a short amount of time. This was great because the team realized quick wins by demonstrating functional pieces of code. The Product Owner and stakeholders were getting continual feedback on the team’s progress. It was a win for everyone!

Operating Agile

I found the experience so amazing I knew I wanted to be an Agile coach. If we didn’t have ours, I don’t think we could have done it alone. The coach was crucial not only to training, but providing support to ensure we were embracing our new agile mindset and not falling back into waterfall processes. It also gave our stakeholders confidence we were working with an expert who could guide our team to success.

Let me know if you have any questions or need help with your transition to agile scrum.

DSC_4880 (500x483)

April Shepherd

April Shepherd
AprilS@gsd.guru  503.307.9072

Contact Us read more

April and Cynthia are GSD Gold

Applying Agile Scrum in the Real World

When I say the word agile and then add the words project management, depending on who you are, your response may range anywhere from “Heck yeah, this is the best thing ever to hit project management!”  to “Agile sucks, it does not work!” How can three little words evoke such a vast array of emotional responses? Because most project managers, developers, analysts, architects and development managers do not really understand agile and they do not correctly apply agile methods.

This is a blog about properly applying agile scrum to get stuff done in the most efficient way possible. Does the world need another blog about agile project management? Apparently, yes it does or else everyone in the world would no longer be using waterfall. Agile, particularly our method of scrum, helps everyone on any project successfully get stuff done, which is a very good thing.

What can you expect to learn from reading our blog posts and participating on our website?

  • How to organize an effective agile team
  • How to rethink your approach to project planning
  • How to setup sprints and monitor sprint progress
  • How to apply concepts of continuous improvement
  • How and when to release

Even more important than learning how to easily apply agile scrum techniques, we will help you shift your current project management paradigm to the agile mindset. Because without changing the way you think about and approach projects, you cannot become agile.

Why listen to us? Yeah and yeah, we both have our PMI PMPs and Scrum Alliance CSMs. We play the game. We both recently attended the PMI ACP 3-day training course, and we wanted to jump out a window within the first two hours. We needed the 21 PDUs, so we stayed the course. By the third day, we looked at each other and said, “Eff this, we can do better!” GSD was born.

That was 3 weeks ago. Now, we have a domain, a website and an outline. We’re agile. We’ll figure the rest out later.

Read our blog so you too can become more agile. We are 100% agile converts. We have taken the leap and left our old waterfall ways behind. We have successfully applied agile scrum to many development projects at multiple companies, big and small. Our agile teams outperform teams of our peers, even teams that also say they are agile too.

We are fun babes to hang out with. Hopefully, you will get as excited about agile scrum as we are. We want to save you from PDU suicide watch and make project management fun!Let’s start hanging out and working together to learn from each other and get more stuff done!

April and Cynthia

April Shepherd and Cynthia Kahn

April Shepherd and Cynthia Kahn

Contact Us

 

read more