Category: Agile Page 2 of 5

Hours vs Story Points – Demystifying Sizing

I’ve worked with many different Agile teams from different organizations. Story points are a common topic of confusion and frustration on teams, particularly new teams. I hear questions like, should we use points or hours? Should we use T-shirt sizes? Should we use Fibonacci? Should we estimate the tasks or the stories?

In this post I’m going to explain how we use story points in Scrum. It is important to note that Scrum does not require any particular sizing or estimating technique. I’m going to explain Story points because it’s one of the most adopted techniques in Agile. The method I’m going to explain is a best practice.

Story points are a number assigned to a story, or PBI (product backlog item), to give it a relative size compared to other items in the product backlog. Before I go any further, let me explain something about “Stories”. User stories are a technique from eXtreme programming which expresses the need from the user perspective. A PBI doesn’t have to be in a user story format. In fact, if the item is not related to a user, don’t waste your time putting into a user story format. Creating a story that says something like “As a BA I need to write requirements so…” is bad. Often we refer to all the PBIs as stories, even though they all may not be in a user story format.

Back to story points. The story points do not equal hours, days or weeks. When estimating story points, the team is trying to figure out how big a story is compared to other stories. The team, those who will actually do the work, estimates the points.

For simplicity, let’s go through a basic example. The Product Owner created a Story which says “As an Admin User, I need the ability to disable other user accounts”. The team then during a backlog planning/sizing session looks at the story and asks the Product Owner questions. After the questions are answered, it becomes clear that the work is small. The team agrees to assign the story with 2 points, using a rough order of size scale like Fibonacci (1, 2, 3, 5, 8, 13, 21). The team then moves on to estimate the next story. The next story reads “As an Admin user, I need the ability to perform batch updates in the system and run real-time reports”. The team has many questions for the product owner about this story. There a lot of unknowns and potential complexity. The team then decides that due to the complexities, the story is much bigger than the previous story. After some back and forth, the team agrees to assign the story with 8 points.

The basic example I provided is how story points are used in Scrum. The points give a relative size to stories in the product backlog. That’s it. It’s not complicated.

Things get a little more interesting with Sprints. Before Sprints start, teams conduct a Sprint Planning Session. This is when the team determines what stories (which are already sized with points) will be completed in the Sprint. For 2 week sprints, it’s advised the planning session should be 4 hours or less.

During the Sprint planning session, the team breaks down the stories into tasks. The tasks are estimated in hours, one day or less per task. Once the time for the tasks is estimated, the team has a good idea of the work they can commit to in the Sprint. They can compare the estimated time of the tasks against their capacity. If they know one team member is on vacation for example, using the task estimates they can better plan for the Sprint.

When the Sprint is in progress, the team updates how much time is left to complete the tasks at the end of each day. This provides the data needed for the Sprint Burn down chart. The Sprint burn down chart shows the time remaining to complete the tasks. The Sprint burn down doesn’t measure completed story points, it measures completed hours of the tasks. Below is an example of a Sprint burn down chart:

Now, up until this point I’ve referred to story points only for relative sizing, with no relation between time and points. Yet, once teams establish a stable velocity (average amount of points they complete in a Sprint), they can use points to forecast release planning and a product roadmap. Although release planning is not a core Scrum event, it is widely used. When teams plan for a release, which may be several sprints in the future, they track using a Release burn down chart. Unlike the Sprint burn down chart, the Release burn down measures the completed story points. The release burn down tracks how many story points remain to be completed to meet the release.

Below is an example of a Release burn down chart:

To recap, Stories are estimated in points using relative sizing, and tasks are estimated in hours, no longer than one day. The Sprint burn down chart relates to time left to complete the tasks in the Sprint. The Release burn down chart relates to points left to complete the release.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

 

The Truth About the Limitation of Scrum

limitation of scrum

There is something I’d like to get off my chest. There is this notion in Agile that project management is no longer needed. Some even think that the role of a project manager will soon be extinct. Before we chase away project managers with pitch forks, lets back up a bit. I’m 100% on board with Agile and with Scrum, but I disagree that the need for project management is going away. The reason is that Scrum has a limitation. It is not designed to deliver large scale projects, at least not without help. The complexities of large scale projects demand the need for project management. This may change at some point, but I don’t see it happening any time soon. And, I’m not sure it should.

I can envision the Agile purists as they read this. Project managers needed in Agile? Scrum has limitations? Blasphemy! Hear me out.

When I refer to large scale projects, I mean projects that could have anywhere between 5-30 changed systems. These types of projects usually include complex system dependencies and a lot of coordination. The systems need to integrate and plan their production releases based on their dependencies. Someone needs to oversee that it comes together, and that someone is a project manager.

On Scrum teams, no, there is no need for a project manager. There are only three defined team roles in Scrum. They are Product Owner, Scrum Master, and the Development Team. Scrum is perfect for teams that focus only on one product or component. As an example, a Scrum team may focus on the search feature of a website.

The need for a project manager shows itself when you have large-scale initiatives. When you have a large project that impacts many Scrum teams, someone must coordinate all the dependencies between the teams. Without a project manager, who will do this? I posed this question in a recent advanced Scrum training course. I then proceeded to watch the instructor twist into a pretzel struggling to answer it. I was then referred to a course offered on Scrum@Scale.

Scrum@Scale, along with LeSS, and SAFe are the popular scaled Agile frameworks. While each of these have their benefits, they also have limitations when it comes to large scale projects. The problem is not scaling more Scrum teams, although that poses a different set of challenges. The problem is managing large scale projects.

In a recent HBR article, Agile at Scale, Jeff Sutherland and other experts discussed large scale Agile projects. They said you can establish a “team of teams” (or Scrum of Scrums), and issues that can’t be resolved can be escalated up to leaders. I’m all for that, but it still doesn’t answer the question of who is coordinating the work of all the teams? They go on in the article to reference Saab’s aeronautics business. “Aeronautics also coordinates its teams through a common rhythm of three-week sprints, a project master plan that is treated as a living document”.

I found it interesting that they referenced a company that uses a project plan in an article on scaled Scrum. This further indicates to me that we need to pause on the idea of abandoning project management.

Scrum@Scale is the model Jeff Sutherland advocates for scaling. In Scrum@Scale, there is a Chief Product Owner (CPO) and a Scrum of Scrums Master (SoSM). They are like the team level Scrum Master or Product Owner roles, but at scale. These roles sound like they will help address the challenge of managing large-scale projects, but there is still a gap. While a SoSM focuses on removing impediments and the CPO on prioritization, you still need someone to look at the project from a holistic view. Someone must coordinate team dependencies, not to mention manage risk, schedule and budget. In short, you need a project manager.

The need for project managers on large scale Agile projects has fueled the rise of SAFe. If you’ve read my post on the problem with SAFe, you know that I’m not a huge fan. But, at least SAFe acknowledges that someone needs to coordinate the work of self-organizing teams on large scale projects. They refer to the role as a Release Train Engineer (RTE), but it sounds a lot like a project manager to me.

Why do Agilest cringe when they hear the words project manager, or for that matter, the word project? When I say there is a need for project management in Agile, I am not saying that projects need to move in sequence from phase to phase like waterfall. I’m not referring to a command and control tyrant who manages Gantt charts with an iron first. Project managers today can lead large initiatives and still follow Agile principles. Projects can still use an iterative experimental process.

You may argue that by creating an architecture where each Scrum team works on an autonomous application, you end the need for a project manager. Spotify is a good example. Lightweight autonomous applications are the way to go, but you still can’t get away from dependencies on large scale projects. In most large fortune 500 organizations, legacy applications are dependent on other systems.

In summary, Scrum has a limitation when it comes to large scale projects. Project managers are not needed on Scrum teams, but they are still needed in Agile for large scale projects. What is changing is not that the Project manager role is going away. It is the role itself that is changing to align with Agile values and principles. The Scrum organizations seem to be working hard to address this limitation through their scaled frameworks, but they have a long way to go.

If you have experienced large scale Agile projects where there was no need for a project manager, I would love to hear about it. I’ve worked for many organizations that have adopted Agile and I’ve yet to come across one that had no need for project management.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Delighting Clients Absolutely Needs To Be The Primary Goal

In 2011, my wife and I went on a vacation of a lifetime. We went to the island of Maui, and we were fortunate to stay in the Ritz Carlton hotel. The trip was a wedding gift from a very generous family member. Had it not been for the gift, my wife and I would have not been able to take such an extravagant vacation.

Staying at the Ritz, surrounded by the beautiful blue ocean and breathtaking Maui views, was an experience we will never forget. Yet, when I look back upon the experience staying at the Ritz, there’s something else that I am reminded of. It wasn’t only the radiant sunshine and palm trees that delighted us. The customer service provided by Ritz Carlton employees was fantastic!

By far, the customer service at the Ritz was the highest quality we had ever experienced. Whether checking in, asking for advice, or saying hello, the staff treated us as though we were royalty. They did this for good reason. They understood that an underlying principle for successful business is to delight clients.

In 1954, in his book The Practice of Management, Peter Drucker said that the purpose of a business is to create a customer. Well, times have changed. While Drucker may have been right that creating a customer was the purpose for business in the 20th century, it’s not good enough today. Increased competition and the advance of technology and globalization have demanded a new way of doing business. The marketplace has changed. Today, businesses need to not only create a customer, they need to delight them.

In Stephen Denning’s book, The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century, he emphasizes the importance of delighting customers. He puts forth principles aimed at moving away from Fredrick Taylor’s outdated command and control style of management. Setting a goal to delight clients is Denning’s number one principle. “The purpose of work is to delight clients, not merely to produce goods or services or make money for shareholders”, writes Denning.

By having client delight be the company goal, it achieves several things. First, clients will promote a product or service if they are delighted by it. Dr. W. Edwards Deming used to harp on this. Dr. Deming said that a happy customer will generate new customers through word of mouth. This effect poses a dilemma for management because it’s hard to put figures around it. It’s hard to measure. Dr. Deming said: “The most important figures that one needs for management are unknown or unknowable”.

Second, delighting clients will inspire continuous innovation. Employees don’t get inspired to produce goods or to increase shareholder value. Employees get inspired to improve people’s lives. Starbucks gets this. Their mission is not about coffee, it’s about inspiring and nurturing the human spirit.

Third, delighting clients fosters a company culture that enriches job satisfaction. Companies that put client satisfaction first, use self-organizing teams. If you haven’t experienced working within a self-organizing team, where you are free to innovate, be yourself and have fun, you are missing out.

The Agile software delivery movement has been leading the way for a new customer focused style of management. Regardless if your business creates software or not, there is much to learn from the Agile movement. It’s the modern way of doing business, with focus not on systems and things, but on people. In Scrum, self-organized and empowered teams build products in short iterations. After each iteration, the product goes to the client for immediate feedback. Shorter feedback loops increase both the product quality and client satisfaction.

The market place today demands a new way of doing work. Our workplace is now made up of knowledge workers, and we must inspire and empower them. Fredrick Taylor’s model of management is not suitable anymore.

Going back to the 2011 vacation my wife and I took in Maui. The experience we had staying at the Ritz Carlton will forever be ingrained in our minds. We learned what it is like to be delighted as customers. For me, I want to emulate that feeling into the clients I serve. At the end of the day, business is about people, not about numbers. If we make client delight the top priority, shareholder value and profits will follow.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Advanced Scrum Training and Meeting Jeff Sutherland

When it comes to Agile delivery, I’m a big advocate for Scrum. Scrum offers an easy to understand and lightweight framework for developing products.

Scrum is great, but it by no means is a silver bullet.  Scrum does not solve problems, it exposes them. It is like shining a big flashlight on your product development team, exposing the good, the bad, and the ugly. Scrum is an adaptive framework, not a methodology.

For most organizations, Scrum is an effective Agile framework. This is particularly true for companies new to Agile. Scrum offers a set of guide posts and rules that make it easier for organizations to get out of their own way. The rules are simple, but not easy. Anyone can get a get good understanding of Scrum by referencing the Scrum Guide.

Last week I got a great refresher on Scrum by taking the Scrum Alliance Advanced Certified Scrum Master (A-CSM) training led by Angela Johnson. Angela is passionate about Scrum, and her and her company, Collaborative Leadership Team, does a great job.

The training was a great reminder that Scrum is about people working together to deliver the highest possible value early and often.

During the training, I had the privilege of meeting and chatting with Dr  Jeff Sutherland . He was teaching a course next door on Scaled Scrum and during a break we met. While we were discussing the challenges of Agile adoption, he gave me some good insight. He told me that sometimes all it takes is one person to start an Agile movement within on organization. He said it’s like someone pulls a lever.

Dr Sutherland relates Agile transformation to the Blue Pill/Red Pill scene from the Matrix. “Take the blue pill, and go back to sleep and continue to use waterfall. Take the red pill, and stay in Agile Wonderland, and see how deep the rabbit hole goes”.

Below is a picture I took with Dr Sutherland.

 

Jeff Sutherland and Mike MacIsaac

Jeff Sutherland and Mike MacIsaac

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Embracing Change and Dotcom Operations

“The Only Thing That Is Constant Is Change” – Heraclitus

Change is necessary in business, technology, and in our personal lives. For me, these past couple of months I have had a lot of change in my life. From moving to a new home to starting a new consulting assignment, change has been abundant. While change can be unsettling, it’s necessary for growth. This brings me to latest consulting role, working in Dotcom Operations.

The picture above shows the monitoring screens located across from where I sit. As you can tell, it’s no small deal. Keeping a live production website running which handles thousands of transactions per second is no small ordeal. To do so, while also adding changes and enhancements, requires talented operations teams.

In my view, operations teams don’t get the credit they deserve. The people I’m working with in web operations are some of the most technical folks I’ve worked with. They are also good people. They are infrastructure engineers, coders, and they work with the latest DevOps technology.

It’s fun learning about the latest technology they’re using in Web Operations. Infrastructure built in the cloud using tools like Jenkins, Chef and Splunk has given me a broader perspective on IT. It’s taken me back to my days testing software in QA, but things have changed. The technical systems for web operations are more advanced than they were five years ago.

Technical systems are always challenging to manage, but what’s more challenging, are the human systems. People need to collaborate and communicate with each other, and this is where I come in to help. The effectiveness of operations teams relies heavily on communication.

To help with communication and the constant influx of work coming in, the teams use Kanban. Kanban uses a pull system to make process better. Below is an example of what you may have seen with a Kanban board.

The core practices of Kanban are as follows:

  • Visualize Workflow – Using Kanban, teams can see the whole visual representation of their workflow.
  • Limit WIP (work in progress/process) – Teams should experiment with WIP limits, which will help improve focus and increase throughput.
  • Manage Flow – By paying attention to how quickly work is getting through the process, teams can begin to improve flow management.
  • Make Process Policies Explicit – Teams should set their own policies on how they can best do their work and improve flow.
  • Implement Feedback Loops – This is about continuous improvement. Just like in Scrum, Kanban teams need to measure their effectiveness and continuously improve.
  • Improve Collaboratively, Evolve Experimentally

Kanban comes from manufacturing and the TPS (Toyota Production System). The below quote is from Taiichi Ohno, creator of the TPS:

“There is no magic method. Rather, a total management system is needed that develops human ability to its fullest capacity to best enhance creativity and fruitfulness, to utilize facilities and machines well, and to eliminate all waste.”

Eliminating waste was a major rule of the original TPS. TPS identified seven types of waste in manufacturing. They are Transportation, Waiting, Motion, Defects, Inventory, Overproduction and Extra Processing.

Years later, Mary and Tom Poppendieck defined the following seven categories for waste in software development.

  • Partially done work
  • Extra processes
  • Extra features
  • Task switching
  • Waiting
  • Motion
  • Defects

An effective way of identifying waste for is through creating Value Stream Maps. Often the biggest bottlenecks occur after development and testing are complete.

Summary

Over the past few years I’ve managed a broad range of IT projects. From working in the insurance industry, to reverse logistics programs, to Web Operations. While this work has commonalities, Web Operations is different. Tackling a constant flow of work is a change for me, and change is good. The change to Web Operations has provided me with two key opportunities. The first and most important, is to provide value and help a talented team of engineers. The second is to learn a different aspect of IT and business.

Are you embracing change in your business and in your life? If you work in software development, are you continually trying to reduce waste and follow lean principles?

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

 

 

 

 

 

 

 

 

Bring IT a Holiday Gift This Season With Good Roadmap Planning

roadmap planing

It’s that time of the year again. Office Christmas party’s and holiday happy hours are in full effect. Most people are scrambling to get last-minute gifts and prepping for time off. Soon the offices will be empty and most of us will be enjoying time over the Holidays with family.

At this point,  most organizations should have a good idea what their IT roadmaps look like for 2018. Businesses usually rank projects based on need and return on investment. This process usually takes place in Q4 as teams prep to get funding for their roadmaps.

Non-IT management of the business typically handle the prioritization process. The idea is, let the business folks decide on what to do, then let the IT folks decide on how to do it.  There’s a lot of logic to this train of thought, and for some companies this works well, but I would tell companies to take caution when using this approach.

The idea that the business should focus on the IT roadmap, without IT involved, is prone for trouble. Yes, the business should be accountable for prioritizing work that provides the most value, but IT should be in the discussion.

When prioritizing an IT roadmap, there are other factors to consider other than financial benefits.  Looking only through the short-term lens of return on investment, you lose sight of the following questions:

  • Which projects are best aligned to the long-term IT strategy for the company?
  • How will the projects affect the IT teams? Are the team’s setup to be successful?
  • How will employees feel about the work? Will those who are doing the work find it engaging, or are you setting yourself up for a mass exodus?
  • How will quality be affected? Are you planning to take on too much work, which could jeopardize quality?
  • If your company is using or moving towards Agile delivery (which it should), how will that affect your roadmap?

Above are a few questions to consider, but you can see why IT leadership should be in the discussion when it comes to prioritizing work for the year.

Aside from IT being involved in the prioritization process, the business should also have a voice in technical solutions. Yes IT is ultimately accountable, but this doesn’t mean the business shouldn’t be in the discussion. When solving technical problems, it’s usually those who work in operations that have the best understanding of the issues. Their’ insights are invaluable.

The need for agile organizations demands that business and IT leadership come together. We can’t afford to have areas of our organizations working in silos. As we begin a new year, isn’t it time we find creative ways for our “business” and “IT” resources and leadership to come together?

About the Author: Mike MacIsaac is the president and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

A Fun Day in Minneapolis – Agile Day Twin Cities 2017

Agile Day Twin Cities

Yesterday I had the pleasure of attending the Agile Day Twin Cities 2017 conference, sponsored by DevJam. The conference aims at helping Minneapolis Agile practitioners learn from each other.   Throughout the day there were breakout sessions which featured different speakers. The talks ranged from the people and business of Agile, to new ideas about improving Agile development.

As David Hussman, the founder of DevJam, kicked off the event, I was impressed by the theme and feel. David made it clear that the event was not about experts and teachers, but instead about learning from each other and challenging the status quo. David also emphasized a focus on product, rather than process. As the event got under way, I was struck by the impressive crowd of Minneapolis Agile practitioners. Minneapolis has become a tech hub and a melting pot for startups, innovation, and entrepreneurship.

Throughout the day I attended many sessions. I heard from other Agile practitioners sharing their experiences. Minneapolis being the small town that it is, I ran into many friends and some former colleagues. One of the highlights was hearing Priya Senthilkumar and Ray Grimmer, former colleagues from my days at PearsonVUE. Priya and Ray talked about their journey implementing stable Agile delivery in a complex environment.

Another talk I enjoyed came from Daniel Walsh. Daniel talked about improving Agile development using the Cynefin framework. Cynefin (pronounced KUN-if-in), Welsh for habitat, was developed in the early 2000s and used as a sense making device. The Cynefin framework has four areas of decision-making: simple, complicated, complex, chaotic, and at the center is disorder. Below is a picture of the Cynefin quadrant with actions for how to respond to each situation.

My take away from the Cynefin framework, is that not all Agile concepts will work well in situations. We need to understand why and where our practices work, and get away from asking questions like, is Scrum better than Kanban? This is the wrong question to ask. We should be asking, what is the situation we are dealing with, and how should we respond to it? We need to get away from a single, recipe based approach for all situations. The way we work in Agile needs to be fluid and smart, and not dogmatic and one size fits all.

I could relate to the concept of the Cynefin framework. I’m sure I’ve been guilty of pushing the wrong Agile framework in past situations. I’ve worked with organizations where Scrum fit like a glove, and in other companies Scrum felt like trying to fit a square piece in a round hole. As the Agile movement continues to evolve, we need to be open to new approaches, ideas and methods.

In summary, my time at Agile Day Twin Cities 2017 was great because it challenged my way of thinking. Sometimes we get so caught up in our work and opinions that we forget to step back and look at things from a different perspective. The new ideas and concepts I heard at Agile Day Twin Cities were great. Perhaps what I enjoyed the most, was connecting with other fellow Agile practitioners.

Below are a few pictures I took during the conference.

Agile Day Twin Cities

David Hussman kicking off the day

Priya Senthilkumar and Ray Grimmer: Agile at Pearson VUE

Daniel Walsh: Improve Agile Development Using the Cynefin Framework

MC Legault: Agile is People & Business!

About the Author: Mike MacIsaac is the owner and principal consultant forMacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog

 

 

We Are Your Trusted Agile Strategy Advisors

Agile Strategy

At MacIsaac Consulting, we build relationships based on trust, commitment, and results. Based on these core values, we provide the very best IT delivery services to our clients. Our goal is to help companies improve the quality of their software products.

We are big on Agile delivery, but it’s clear to us that many organizations still have an Agile delivery problem. The problem is that companies rush into Agile adoption too soon. In short, they lack strategy! The results are high Agile training/coaching fees and little results. For those organizations who have felt this pain, we hear you!

To address this problem, we help companies create an Agile strategy. We do this through the following three-step approach:

  1. Detailed assessment of your current state IT delivery capabilities (where you currently are).
  2. Strategic recommendations and goals for your Agile adoption (where you need to be).
  3. Partnership options to help you meet your goals (how we can help you get there).

Together we will create an Agile adoption strategy that’s tailored for your organization. Whether you are a large or small company, when it comes to Agile adoption, there is no one size fits all.

We are agnostic to any particular brand or framework of Agile. Our approach includes all aspects of how you delivery software. This includes both business and IT. Too many companies make the mistake of only focusing on their IT teams, but business and IT must work together as one.

We insist that business leadership understands the principles behind Agile delivery. This is so important to a successful Agile delivery transformation.

For more on our Agile advisory services, I encourage you to reach out to us. We are a small team of seasoned IT delivery and Agile experts. All our consultations are at no cost to you. Our ultimate goal is to set you on the right path.

We want to hear from you! We are here to be your trusted Agile strategy advisors.

For an intro to MacIsaac Consulting, see my short video below:

 

About the Author: Mike MacIsaac is the owner and principal consultant forMacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog

Have People Had Enough Of Agile?

Agile Delivery

Photo Credit Shutterstock

If you work in a business that has anything to do with technology, you are familiar with Agile. You know the Agile I’m talking about. The kind where teams sit together and deliver software in increments. Seems everywhere you turn these days you hear about Agile. Along with Agile’s popularity has come a title wave of services. These services include coaching, training and certifications.

Consultancies have jumped on the Agile bandwagon big time. The other day I noticed a local consulting firm completely re-branded themselves. They are now the Agile experts. I was like wait, what? Like a year ago, they didn’t even provide IT consulting. Anyway, you get the point, Agile is the flavor of the moment and it’s everywhere.

Along with the over promotion and saturation of Agile, there has also been a mass influx of Agile gurus. These gurus scour the internet to prove their Agile knowledge is second to none. Agile to them has become a religion. They are quick to scold anyone blasphemous enough to challenge their Agile expertise. If you follow any Agile groups on LinkedIn, you’ve seen the ridiculous feuds. For sure the gurus will comment on this post to teach me the error of my ways.  Dealing with these gurus online is bad, but if you’ve had to work with them, it’s even worse.

So, between the obnoxious gurus and the commodification, I must ask, have people had enough of Agile? Is Agile software delivery like the glam hair metal of the 80s, and we’re at the point of Nirvana and grunge breaking onto the scene?  Keep in mind that as I ask this question, I’m a pro Agile guy. For many years, I studied and worked in both the Agile and traditional SDLC worlds, and today Agile is my preference. Although I’m a pro Agile, I’m concerned about what Agile has become.

To back up a bit, I started my career back in 2000 as a manual software tester, long before Agile exploded onto the scene. For years, I tested software for various organizations. Around 2008, I got introduced to Agile when I worked as a QA analyst on Scrum team. After time, I started working as an IT Project Manager and an Agile Scrum Master.

I studied everything I could on project management and on Agile delivery. I got my PMP and in business school I studied systems thinking and the theory of constraints. I attended Agile training, got a CSM (Certified Scrum Master) certification, and read every book I could on Agile.

Today, I still consult as an IT project/program manager or Agile Scrum Master. Although my preference is Agile, I’ll perform whatever the client role requires. Usually this means being a traditional project manager, an Agile Scrum Master, or a hybrid of both.

I have a real appreciation for Agile delivery. I found that the Scrum Master role coincides with two of my other passions, leadership and emotional intelligence. I love how Agile delivery is not only about writing code, but also about relationships and working together as a team.

As much as I’m a fan of Agile, I still think there is value in traditional project management. There are disciplines and processes that are tried and true in project management. We need to be careful not to write them off. Not all organizations are ready for Agile adoption, and that’s okay. I know that may sound odd coming from someone who is pro Agile, but if we are honest, Agile adoption is not easy. It isn’t as simple as attending a training. There are some great training services available, but often they have little effect.

All this leads me back to question, have people had enough of Agile? Am I, and pro Agile people like myself, part of the problem? Have we lost sight of the Agile Manifesto and become too dogmatic in our views, turning others off?

Soon Agile will morph into something else. New delivery frameworks will emerge, and so will new gurus. Whatever happens, it’s important we open ourselves up to not having all the answers, and we remain teachable. The main goal is that we continue to improve how we develop software and work together. To me, the Agile movement is a part of something bigger than certifications and gurus. It’s about working together to build quality products that provide value. What say you?

About the Author: Mike MacIsaac is the owner and principal consultant forMacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

6 Steps To Take Before Making The Agile Transformation Plunge

With the popularity of Agile, more and more executives are pushing Agile transformation. To meet this demand, everywhere you look someone is now selling Agile. In a sense, Agile has become a commodity.

Agile Transformation

Those selling the commodity offer things like Agile coaches, Scrum training, and SAFe certifications, just to name a few. Don’t get me wrong, many of these vendors provide high quality services. The commoditization of Agile is a result of demand due to the positive brand that is “Agile”. When done right, few will disagree that Agile isn’t the best way to develop software.

When it comes to Agile transformation, the problem is not so much the Agile service providers, but more so around a lack of planning. Without proper planning,  the “transformation” process often goes over like a lead balloon.

The scenario usually goes something like this: executive from company X declares the organization needs to be Agile. Management then scrambles and hires Agile coaches and force employees to sit in open-work spaces. Throw in some team stand-ups and burn down charts and voila, they are now Agile! Management is happy, that is, until time goes by and they realize they have no measurable improvements.

Here’s the thing, Agile transformation is a huge change. If you haven’t properly planned before charging into transformation, your chances of success will be slim.

Another way to think of Agile transformation is like getting yourself in good physical shape. Last year I started working with a personal trainer. When I first met with my trainer, he didn’t send me right into the weight room and have me do dead lifts and squats. Instead, we met on multiple occasions and talked through my eating habits, my fitness routine, and my goals. We did this before I went anywhere near the weights.

By taking the time to do the analysis, I got a clear picture of where the problems were with my current fitness routine (or lack thereof) and diet. This enabled me to come up with goals and a manageable plan to achieve them. I was then able to put the plan into action and with the help of the trainer, receive some great results.

It’s the same with Agile transformation. You need to take the time to analyze and plan before charging ahead. If you’re planning to bring in Scrum training and Agile coaches, I’d like to propose some steps to take before doing so. Below I have outlined 6 steps intended to help you be successful in your Agile transformation journey. Think of them as Agile transformation prerequisites.

1) Know Your Organizational Purpose – Make sure you are clear on what your definite purpose is as an organization. You might be asking, how is the purpose of my company related to Agile, isn’t Agile an IT thing? It’s funny, many of us in technology sometimes forget we are part of a bigger picture. Business and IT must be aligned on the definite purpose of the company. If you don’t know the purpose of your company, then you have a bigger problem to deal with then adopting Agile. By knowing the definite purpose of the organization, you can align your Agile transformation strategy with the mission and goals of the company.

2) Know Your Current Value Stream – Get a clear picture of your current end to end process for delivering product or service. Many companies have different departments responsible for their part in the sausage making, yet nobody understands the full end to end process. Remember, if you’re going to make improvements, first you need to understand what needs to be improved. Saying that you want to become more Agile is not good enough. That’s like going to a trainer and saying that you want to be healthier. You need to get specific and find out what’s going on.

One way to do this is to sit in a room with management and white board out your current end to end process. Start from the beginning of new product idea, or customer order, all the way until the product or service is in the hands of your customer. This includes your business funding and prioritization process, and project planning and delivery. Include all your processes and steps for delivering your product and service. While you are doing this, write down the actual work time it takes to complete each step in the process, as well as the wait time. What you’re doing at this point is getting a clear picture of your delivery process, while also identify constraints in your system. For more on the benefits of this process, see my post on the theory of constraints and value stream mapping.

3) Know your constraints – The next step is to identify the clear bottlenecks in your delivery process. For example, if you find that on average it takes your company 1 year to approve new projects for funding, you’ll know you have a constraint way up-stream in your delivery process. Agile transformation is not only about making changes to your IT teams, it’s also about changing how your business operates. The idea is to be lean and efficient while providing high quality products to your customer.

4) Know your employees – Take a good look at your people. Are they open to change? Do they bring a positive attitude and contribute to a healthy culture? How about your IT people, are things like paired program and test driven development foreign concepts to them? Take a good inventory of the soft and hard skills of your employees. This is important because if you don’t have the right people, your Agile transformation efforts will fall flat. Get to know how your people really feel about Agile. What you don’t want is people who pretend to be on board with Agile, but bad mouth it at the water cooler.

In my experience, if you have people who are open and willing change, and are positive, you’ll be in good shape. You can teach the technical skills but trying to change someone’s attitude is a whole other ball game. Agile is all about collaboration and working as a team. You need great team players.

5) Know your technology – Analyze your current applications and delivery system. What type of infrastructure do you have in place? What’s your technology stack? Are you using physical or virtual servers? Are you using cloud technology? Take the time to do a full inventory of your technology and its health. How about your testing and deployment capabilities, are you running any automation? You need to know what kind of technology you’re working with. If you company uses archaic technology, it may be time to upgrade. Agile is a modern software delivery practice, you should aim to complement it with modern technology.

6) Create goals and an action plan for Agile transformation – After doing a thorough analysis of steps 1-5,  now you’re ready to create a tailored action plan with goals. This is where you decide what Agile framework to use, or combination of frameworks. At this stage you are now ready to engage outside help for Agile training and coaching, based on your goals.

By going through all the steps, you may be surprised what you discover. Your teams may be more Agile than you think. Only through proper analysis can you discover what is working and what needs to change.

If all this seems too daunting, or if you have already brought in Agile coaches yet see little change, at MacIsaac Consulting we can help. We act as trusted advisers to help organizations put the right Agile transformation plan in place.

We are Agile framework agnostic. Our goal is to tailor a plan that what works best for your company. With Agile transformation, it shouldn’t be a one size fits all approach. Just like someone’s fitness goals, each organization will have different goals and strategies to achieve them.

So take the proper steps, because you and your organization deserve a successful Agile transformation!

About the Author: Mike MacIsaac is the president and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

 

Page 2 of 5

Powered by WordPress & Theme by Anders Norén