Our Agile Journeyhttp://ouragilejourney.com
Constantly Improving Business Processes.Thu, 21 Jul 2016 17:25:09 +0000en-UShourly156923453More Than A Processhttp://ouragilejourney.com/2016/03/17/more-than-a-process/
http://ouragilejourney.com/2016/03/17/more-than-a-process/#respondThu, 17 Mar 2016 16:20:58 +0000http://ouragilejourney.com/?p=816Imagine being tasked with learning to play jazz. Working the scales. Memorizing songs. Over time you would develop a level of talent regardless of passion. You would probably even get good enough for gigs with a local bar. This would probably be good enough to fulfill the task of learning jazz. It wouldn’t get you to the level of Louis Armstrong though.

Stuart Miles – www.freedigitalphotos.net

Attempting to move your team to Agile is the same. Put the proper processes in place. Follow the rules. Over time a new pattern of work develops, one that is more Agile-like than the previous one. This new paradigm plateaus. It’s probably different enough than what was done before that everyone looks and says “yep, we’re Agile now.”

Over time the management that wanted the team to go Agile is going to get frustrated though. This new paradigm, it’s not what she wanted. She was promised continuous improvement. She thought the team would become high-performing. She was expecting to have a product to market more quickly, and more relevant to that market when it arrived. Something went wrong.

This is not a process problem. In fact, evaluating the teams process against the rules of Scrum, Kanban, SAFe, or whatever agile process was chosen is likely to result in their process passing with flying colors. The problem is that Agile is more than just a process.

All of the current popular Agile methods can trace their inception back to a single meeting. A single point in time where the concept of what we now think of as Agile was born. This meeting was focused on software development and the people there likely had no idea just what their ideas would turn into. This meeting is where the Manifesto for Agile Software Development was born.

The problem with many disappointing and failing attempts to convert teams to Agile are due to the focus on process. Think of Scrum for a minute,since it is the most popular vehicle for an Agile transformation. There is a defined framework for the team to base their work around. There are defined meetings, a suggested rhythm, specified roles. A company will often implement this exactly as stated and then start tracking how well the team adheres to this framework. They will focus on making sure they follow the process. Often the former Project Manager is made the Scrum Master (since there is no PM in scrum) and put in charge of the process. They then become the primary driving force for the team.

This is something most PM’s feel they can jump right into. Maybe they even take a three-day course to learn the Scrum process, another tool in the PM belt. They then go about setting the framework up and ensuring everybody gets to every meeting they are supposed to. They religiously update the progress board every day, drilling the team for progress reports at the daily stand-up to get the information they need. They present that progress to upper management every week. They make sure that everyone knows what they are supposed to do for the sprint at each sprint meeting. It all looks right on the surface, but things haven’t really changed.

Sure, the meeting schedule has changed. The speed of delivery might even change. The process is definitely different, but it isn’t Agile. It’s really just another form of what was happening before.

Making a transition to Agile isn’t just about the process used to accomplish work anymore than being a great musician is about pushing notes out properly. There is something more needed. The team, just as the musician, has to believe in what they are doing. They have to be invested in it on a personal level. If all they do is follow a new process nothing will change.

Is your Agile transformation stalled? Maybe you need to stop training the rules of the process in place and consider having everyone step back and define how the rules represent the manifesto, and how the rules might need to change. Then support them as they experiment with changing them.

]]>http://ouragilejourney.com/2016/03/17/more-than-a-process/feed/0816Bring Yourselfhttp://ouragilejourney.com/2016/02/25/bring-yourself/
http://ouragilejourney.com/2016/02/25/bring-yourself/#respondThu, 25 Feb 2016 17:39:29 +0000http://ouragilejourney.com/?p=788I’ve recently finished a period of time as an IT Project Manager. At its heart this was a classic PM role. Capitol projects, such as updating a corporate PBX System, were at the heart of the job responsibilities. Those who know me well or followed this blog in the past might be surprised at this. I know when I speak to recruiters here in the Denver area they always are. That aside my big question as I started that position was what can I, as an Agile Practitioner, bring to this classic project management role?

Image courtesy of stockimages @ freedigitalphotos.net

At the start I made a tweet about bringing Agile to the company. Of course this is not something that one can just do, like bringing a stand-up desk. (Which I did near the end of my time.) Agile, especially as related to project management, is a way of working, a style, an approach.

After a week or two of settling in and finding my place on the team my goal was to excel in the job being asked of me. My efforts shifted to how I could do that. I was part of a team that ran very lean. We were under the direction of an extremely intelligent woman. All the projects I was involved in were already underway at some level. I was getting a good idea of what they required and where they were struggling, if they were. Thing is, what they required for the most part wasn’t anything I could easily pull from my Agile and Scrum background.

I started by concentrating on visibility. I wanted to make the real status of the projects as compared to their end state documented and visible to all the stakeholders. This allowed progress on the projects to be tracked and improved upon, but wasn’t anything special.

What I really wanted to bring something unique to the projects. Getting proper tracking and reporting in place didn’t do that. I worked on learning some of the solutions so I could help optimize them and make them work better as we tried to finalize deployments. This was useful and it helped get things done more quickly, but it still wasn’t quite right.

Something said to me by my boss stuck with me on it and to paraphrase it was that I needed to bring myself to the project. Not just be there as the Project Manager, but be there as the Project Manager with 14+ years of tech industry experience and knowledge. This is ultimately what started to give me more confidence in making recommendations and decisions for these projects. This is also the biggest take-away from my time in that position.

As you move forward in new projects, on new teams, and in new organizations don’t spend all your time trying to change into what you think the teams expects you to be. You were hired to fill a role yes, but it was you that was hired. Bring what you have learned before to what you do next. That is the only thing you can do that nobody else can. Everything else you bring is good, but the uniqueness of your experience and expertise is what will allow you to succeed going forward. It’s what I plan to bring forward in my next adventure.

]]>http://ouragilejourney.com/2016/02/25/bring-yourself/feed/0788Why I am not postinghttp://ouragilejourney.com/2015/09/02/why-i-am-not-posting/
http://ouragilejourney.com/2015/09/02/why-i-am-not-posting/#respondWed, 02 Sep 2015 05:16:20 +0000http://ouragilejourney.com/?p=782I thought I would share a little about why this blog has been relatively silent lately. Some of it may feel like excuses while some may look like legitimate reasons. The truth is that there probably are a little of both.

stockimages – freedigitalphotos.net

I get my blog posts from two sources. First I read lots of other blogs and some books. Second I use experience in my job and to a lesser extent my personal life.

As I have mentioned in other easy to find outlets I am now employed as an IT Project Manager. This is a good thing. It helps keep the family fed and clothed. The person whose house we’re living in kind of expects some money back for the privilege. Pretty standard stuff really. It does limit my time for reading the blogs I used to keep up with. As I settle into this new position I hope to start gaining some time to keep up with relevant blogs again. As of now I am still in “fire-hose mode” and pretty exhausted by the new environment and routine by the time I get home. Basically, I don’t get much of the extra reading done I used to. I will also start getting ideas for blog posts from my work environment as time goes on. As anybody that works and writes about related topics knows this is a bit of a tension to manage. Historically I do this two ways, obfuscation and delay.

I try not to mention the company I work for when writing. It’s not hard for anyone to figure out if they want. Also, I’m human and have been known to make mistakes from time to time. I also do not mention people by name. I try to de-gender my writing as well, but I’m pretty bad at that. Finally, I tend to be as general as possible about the specific situations/technologies/ect when writing.

I’ll give an example from a long time ago at a previous job. Even so, I’m not going to mention the company. (Doubly safe due to it no longer being said company…) The situation was a need to increase collaboration between disparate campuses. I would have shared that at face value. I would have even been willing to go into some detail about how the network connections were fairly standard Cisco vpn tunnels over T1 lines for the most part. I think the main office had dual T1s. It sounds slow now, but it wasn’t bad for the time. The data we were trying to share between campuses was large CAD files and file groups. We were trying to make it so someone from any location could work on CAD files at any other location without incurring a huge slow-down. I would have hedged this a little. I might have framed it as sharing databases between sites or just calling out “drawings” instead of CAD specifically. Basically, the least amount of information I could give to convey that the files were huge, but the changes made were usually relatively small. Also, file locks and constant communication between the workstation and server where the file was hosted came into play. I would have articulated that as well as I could. I would’ve mentioned that I was doing the primary research and we had two stakeholders outside the IT team doing ancillary research. I would have mentioned our testing methods on the solutions we tried as well as I could with the level of detail already mentioned. Finally, I would have stated the specific solution we decided on because it was that good for us. (Riverbed caching and compression servers. They worked really well.)

All of this would have been posted about a month or two after the fact, or at the very least offset by a week from the actual events. This is the time-shifting portion.

Basically, my posting goals include as generic of data as possible. This not only protects my company and team, but also allows more people to see a way to apply the concepts to their own situation. My other posting goal is to delay enough so that if identities are compromised it has no negative effect.

What this means going forward is that I will slowly pepper out some posts here and there for probably the remainder of the year. By then I may be able to start peppering out posts inspired by work. Barring that I should be more in tune with the routine such that I can get more reading done and add my thoughts and commentary to the conversation.

There is one thing that may change though. This position and environment is pretty different from my previous development one. That means my work inspired posts are going to start skewing more towards project management and further from software development. That said, I still see it as an Agile Journey. I intend to approach my work with an Agile mindset in this new role just as much as I did in my previous one.

Has anyone else made the transition in the last few years from development/scrum master to project management? I’d love to talk about your experience in the transition.

Some people interpret this to mean the more software that gets delivered the better. They even point to short iterations which include deliverable’s as a manifestation of that. More rapid delivery can even be a selling point to launch an Agile transition. Thing is, the goal isn’t more software, it’s valuable software.

Everybody that has worked in software development for any length of time has heard of “Feature Creep.” You don’t even need to be in software to understand the concept as it’s been around projects for a long time. While I can’t prove it, I wouldn’t be surprised to learn it has been around since before the pyramids were an active construction project. The basic notion is that as the project progresses more and more functionality is crammed into the product being delivered. This is something that generally pushes release back, drives up costs, and threatens quality. It can even result in lots of (potentially unpaid) overtime as people involved try to prevent it from affecting the schedule. This is “affectionately” known as a “Death March.”

The classic project management practice to deal with this is Change Management. The Project Manager intercepts incoming changes and routes them through some kind of acceptance criteria. This minimizes the shift from what was originally planned and helps to maintain the schedule and budget.

Approaching the same problem with an Agile mindset results in a very different environment. The final deliverable will have the minimum responsible amount of definition to being with. Changes to the final product will be welcome as the project progresses. The schedule will not have to be affected as any changes will be agreed upon by the people doing the work and the people wanting the product through regular communication. Ideally there will be some useful form of the final product available starting early on which improves over the life of the project.

Where we really see a difference here is that the classic approach provides all of the original product vision as well as the approved changes over time. It provides more functionality. This isn’t necessarily a good thing. Many people are familiar with the 2002 Standish Group Study stating that 45% of all developer features are not used. (Some info on it if you aren’t.) The Agile approach trims things that are discovered to be less important than new things as the project goes on. The end result has less functionality due to avoiding the death march, but the functionality included should have a higher utilization.

This is something we should be taking to our management. Increasing productivity is a neat idea but it is likely a red herring in most knowledge work. A better idea is to increase the value produced. In some cases this might be a volume question. If your target market wants a lot of trashy novels, then more value is found by increasing volume. If your target market wants a single definitive guide to writing unit tests then more volume isn’t the way to go, better information in a single volume is.

It’s the same for software. Giving the accounting department tons of bells and whistles in their new account management software is nice, but if they are only going to use the core set of account payable/receivable functions and not touch the rest you have failed in value delivery. You could have given them the core functionality when it was done instead of making them wait for all the bells and whistles. Instead of building those bells and whistles you could have refined the core functionality.

Next time you’re looking at what the end result of a project will be and how to get there take a moment to step back. Consider what the true value is and put some methods in place to deliver better value over time instead of spending all of your time trying to increase productivity.

]]>http://ouragilejourney.com/2015/08/04/value-over-productivity/feed/0755Still Herehttp://ouragilejourney.com/2015/07/01/still-here/
http://ouragilejourney.com/2015/07/01/still-here/#respondWed, 01 Jul 2015 15:08:25 +0000http://ouragilejourney.com/?p=767I just wanted to let out a quick note to let people know I am still here. We have made the trip to Colorado and are close to settling in.

Ambro – freedigitalphotos.net

The trip went well and the move itself has been largely outsourced. We have a rental and it is ready for our stuff to arrive soon.

I am going to be living in Castle Rock for the next 2 years. I am currently open for opportunities to come in as a Scrum Master, Agile Coach, or IT/Agile Project Manager. I can help your organization make an Agile Transition on a full-time or temporary basis. Feel free to contact me and we can talk about what we’ll be able to do for each other.

That said, I haven’t been sitting around doing nothing. I am actively seeking out positions similar to what I mentioned above.

I do have a post partially written and a couple more ideas sketched down in preparation for getting back on schedule. I anticipate getting back to my regular once every two-week rhythm no later than the end of July.

]]>http://ouragilejourney.com/2015/07/01/still-here/feed/0767Product Owners and Scrum Masters: Partners in Adversityhttp://ouragilejourney.com/2015/06/02/product-owners-and-scrum-masters-partners-in-adversity/
http://ouragilejourney.com/2015/06/02/product-owners-and-scrum-masters-partners-in-adversity/#respondTue, 02 Jun 2015 18:40:48 +0000http://ouragilejourney.com/?p=746Despite their differing priorities a Product Owner (PO) and Scrum Master (SM) must be on the same team. More specifically, in a successful scrum team the PO must be a partner to the SM. Their adversity comes from the roles they play. The sentiment applies equally well to Agile Project Managers and Agile Coaches. That said, framing it in the context of Scrum makes the narrative easier.

meepoohfoto – FreeDigitalPhotos.net

The PO is beholden to the customer or end-user as well as the business. Their main function is to maximize value delivery. The SM is beholden to the team. Their main function is ensuring and enacting scrum through servant-leadership of the team. With no SM a PO might very well burn a team out by requiring too much of them. Without a PM a SM might hinder value delivery by shielding the team from more than they should or allowing more experimentation than the business can support. Hence a partnership must form between the PO and SM for a successful team to emerge. The adversity arises due to the difference in priorities between these two roles.

The PO and SM have to work together to find the right balance between pushing the team for higher performance and sustaining the team for long-term endurance. Together they need to know what level of change is tolerable by the organization, the user, and the team at any given point. Using this knowledge, they need to decide how much time the team can spend on self-improvement versus value delivery every iteration. In a solid partnership they might be able to discover ways to accomplish both improvement and value delivery at the same time.

Just as changing around a development team causes a reset of the teams development changing the PO or SM does the same for their partnership. Having multiple PO’s on a single product exacerbates the problem, and is a bad practice to begin with. The PO is supposed to be the one and only person who can speak to what the most important deliverable is at any time. If there are multiple people trying to fill the role there will inevitably be a time where they disagree, potentially causing confusion when the SM is looking for clarification or guidance. Similarly, a dedicated SM can establish a relationship with the PO and continue through storming and norming to performing. Choosing to instead rotate the SM role among team members can result in that relationship never progressing beyond the storming phase.

When a PO and SM are on the same page it becomes easier for the team they are on to deliver the best value possible. If they are at odds then their conflict itself will become a value blocker for the team. Keep both roles dedicated, on the team, and in a partnership for the best outcome possible.

]]>http://ouragilejourney.com/2015/06/02/product-owners-and-scrum-masters-partners-in-adversity/feed/0746Revisited: Agile is not Scrumhttp://ouragilejourney.com/2015/05/19/revisited-agile-is-not-scrum/
http://ouragilejourney.com/2015/05/19/revisited-agile-is-not-scrum/#respondTue, 19 May 2015 18:36:30 +0000http://ouragilejourney.com/?p=733While continuing to prep for my families move to Colorado next month I have decided to revisit a post or two from before. I may take a week off from writing as well.

atibodyphoto – freedigitalphotos.net

This post found widespread reading when it was first published in November of 2013. I’m adding it here as it was early in this blogs life and many people may have missed it back then. If you have seen it before all is not lost. I have gone through it and done some editing to make sure it’s still relevant.

When looking for information on Agile, software development is the most common industry represented. Within those results more often than not Scrum is used as the implementation. Many articles that try to talk about Agile in a generic sense use terminology from Scrum. A common side effect of this is that many people associate Agile and Scrum on a 1 to 1 level. This is a problem.

Agile is flexible.

One of the main concepts in Agile is that we do not know what we do not know. As we go through a project there will be new information. In being Agile we admit that up front. We start the project when we have the least information needed. We make decisions at the last responsible moment. We often take breaks to see what we have learned. We look at what has changed from our original understanding. We examine what works and what doesn’t. Most importantly, we use that information to incorporate changes to the project or process as needed.

Scrum is well-defined.

To be considered Scrum there are very specific rules that must be adhered to. If any of them are missing Scrum is not truly taking place. If any of them are in place in name only then at best “Scrum-but” is taking place. The entirety of what is required for Scrum to happen can be condensed into a 16 page guide or a 20 page primer. Anything less and it is not Scrum. Adding doesn’t mean it isn’t Scrum, but the additions are not Scrum.

Agile guides decision.

The heart of Agile is a set of values. Drilling down to the next level of Agile as defined for software development are a set of guiding principles. In none of the values or principles is an edict for activity made. They are all ideals to keep at the forefront of decision-making. They are meant to shape how a project is approached, not dictate the method used for accomplishing work. Gil Broza’s upcoming book The Agile Mindset goes into much more detail on this.

Scrum dictates process structure.

The heart of scrum is a set of roles, events, and artifacts. The roles people play on a project team are consolidated to one of three named positions. There are specific meetings that must take place every iteration. Work must be structured and queued in a certain way. Inside of this defined shell is Scrum. Outside of it is something else. It may be more, it may be less. It may contain Scrum, but it is not Scrum.

Agile is a way of thinking.

Agile thinking can benefit any project. Agile thinking is something that can be done in many different working environments. An Emergency Room can be run as an Agile project using a method such as Kanban. Agile thinking is open thinking. Open to change. Open to improvement. Open to modifications. Agile thinking allows for bonds to be as broad as practical. Agile accepts risks and work with them, trying to minimize them instead of eliminate them.

Scrum is a framework for getting work done.

Scrum is specific to product development, specifically software development. Scrum allows for flexibility, but only inside of the framework. Anything that is outside of the framework is an addition to scrum. It is allowed, but only if it does not undermine the framework itself. Anything removed from the framework means Scrum is no longer happening.

Scrum is Agile but Agile is not Scrum.

Just as all cars are vehicles but not all vehicles are cars Scrum is Agile but Agile is not Scrum. Scrum is something that, when used properly, is Agile. It allows for constant, short feedback cycles. It allows for continuous improvement. It gives transparency to the people who need it. Agile allows for more. Agile allows the framework to change as needed to best deliver value to the customer. Agile allows people to be placed in front of defined roles.

Scrum is a good place to start an Agile journey. It is simple on paper and in concept. It is widespread and shows a lot of success over the last decade. It is well understood and the benefits can easily be explained to the organization at large. The structure for Scrum can be mapped out and placed in an organization in a very short time frame. As an Agile Coach I would default to Scrum for most software development environments at the outset. In the end though, Agile needs to be more important than Scrum. Scrum is going to work. It might even be the best solution. Once a team trends towards high-performing the framework of Scrum must not be a limiting factor in improving the product and performance of that team. For this reason, even though I would start as Scrum, as an Agile Coach I would be open Scrum-but over Pure Scrum in more cases than I would be blatantly against it,.

]]>http://ouragilejourney.com/2015/05/19/revisited-agile-is-not-scrum/feed/0733Odds and Endshttp://ouragilejourney.com/2015/05/05/odds-and-ends/
http://ouragilejourney.com/2015/05/05/odds-and-ends/#respondTue, 05 May 2015 20:54:04 +0000http://ouragilejourney.com/?p=721It’s time for a short break from our usual format. No, it’s not a retrospective post, although I have done that before. (Now that I think of it, I should do another one soon.) This break is due to personal change resulting in a lack of research and writing time the last two weeks. That change? I’ll get there in a minute. First I want to share what is sure to be a great interview with you.

taoty – freedigitalphotos.net

Marcus Blankenship will interview Gil Broza on Thursday, May 7, between 2-3pm PT / 5-6pm ET. (Google Hangout or Youtube available.) The interview is centered around Gil’s upcoming book The Agile Mindset. I’ll start by telling you that if you haven’t read The Human Side of Agile you need to. The first value in the Agile Manifesto is People. This book helps remind us of that. The next thing I’ll tell you is that I’ve been allowed time with a preview version of The Agile Mindset and it goes deeper into every part of the manifesto. I’ve started a similar track with my Back to the Basics series, but Gil goes to the next level with it. If you’ve plateaued with your Agile implementation this book will help you look at your work differently and get past that. I look forward to the interview and hope you check it out as well.

The other thing I want to share this week is that I’m moving. Not the website, actual me. As of July I will be in the Denver/Colorado Springs area. Whether you want to investigate Agile for your company or bring your teams to the next level I would love to discuss how I can help. Alternately, if you know anyone looking for an Agile Coach, Scrum Master, or a Project Manager in an Agile environment please let me know. My résumé and a cover letter are on the about page.

]]>http://ouragilejourney.com/2015/05/05/odds-and-ends/feed/0721Avoiding a Rough Starthttp://ouragilejourney.com/2015/04/21/avoiding-a-rough-start/
http://ouragilejourney.com/2015/04/21/avoiding-a-rough-start/#respondWed, 22 Apr 2015 02:15:04 +0000http://ouragilejourney.com/?p=609Often organizations will start an Agile journey by sending their project managers and/or development leads to Scrum Training. Upon their return they are expected to implement Scrum with their new training and knowledge. Sometimes this is driven by one of the groups sent to the training, but often it is an edict sent down from upper management. In either case this is setting the organization up for a rough transition to Agile.

Naypong – FreeDigitalPhotos.net

In general smooth agile transitions require more than an internal employee bringing info in from a two-day course. Support is needed from every level of the organization to make things work. Involvement is needed from everyone who will be working on the project teams. Different roles need different training to succeed with their new process.

Sending someone to training is a good start to the transition. A better start would be to send an entire team. This shouldn’t be a team of project managers, but the pilot team making the initial switch to the agile method of choice. This prepares the pilot team for success.

When the team returns they should meet with their management support. Two important things happen here. On one side management can communicate the hopes they had in starting this process. The other side is that the team can communicate what they expect to see happen in the first six months. This doesn’t have to be a confrontational time. Management saw some possible value in this to begin with or they wouldn’t have sent the team off. Bringing in an outside consultant can help keep everyone on track. The team is new to the whole thing, but should know enough from training to set some initial expectations for management. Chances are the team will not be able to transform as radically as management initially thought. On the flip side they should be able to promise greater transparency into what is happening during the transition than management expected.

With an entire team trained and proper expectations set between the team and management the actual transition can start. In a perfect world the team is working on a project that requires nothing from other teams which may impact the new processes they are putting in place. In reality they will likely be interfacing with teams that are not agile and not working to get there. This is where the team all being trained in agile values and principles can be more valuable than the specific method training they have received. Most of the current popular agile methodologies do not deal much with interfacing outside of the team. They tend to assume the team itself will be doing everything from start to finish with no reliance on the outside.

Even with these pieces in place it’s not guaranteed that the transition will be smooth. In fact, real-world evidence is showing that the transitions are almost always rough. By getting everyone trained, on-board, and supported that roughness can be smoothed out. Bringing in outside help is another way to help smooth out the rough spots that are tough to see from within.

]]>http://ouragilejourney.com/2015/04/21/avoiding-a-rough-start/feed/0609Agile During Maintenancehttp://ouragilejourney.com/2015/04/07/agile-during-maintenance/
http://ouragilejourney.com/2015/04/07/agile-during-maintenance/#respondTue, 07 Apr 2015 16:47:02 +0000http://ouragilejourney.com/?p=701When a team builds a house the project has a very defined end. Once built the original team no longer deals with the house instead handing maintenance and support over to the user. Software development is not like that. Once the initial release is done the original team generally does deal with maintenance and support. When the last release is done they generally still deal with maintenance and support.

khunaspix – freedigitalphotos.net

This can be tough for some people tasked with managing agile software projects to reconcile. Projects are supposed to be temporary and have a defined end. Once a project is done it’s time to move on to the next one.

A good way to get around this mindset is to change the delivery. Don’t think about the software as a product to develop and deliver. Think about the software as a value delivery system. Your team is not creating this single product which will then be passed off and forgotten. Your team is creating value for the user. As long as there is more value in enhancing or fixing the software then there is in doing something else for that user then your team should focus on the software. That brings us to how we deliver more value on a product that is out the door. My answer, admittedly biased, is with an Agile mindset.

In shifting our focus from delivering a product to delivering value we are already well on to our way of using agile methods, process, and tools. The first principle listed on the Agile Manifesto is about delivering valuable software. The argument may be that the valuable software has already been delivered. The user may disagree. They may see more value in the software doing something new. Perhaps upon using the software they discovered that what they thought would be a valuable addition is in fact problematic. This new realization means that better value would be found by changing the software.

Creating a massive project to implement a change to an existing product may not be the best use of resources. This new revelation, it’s a changed requirement. It’s not in the original plan. This speaks directly to another principle of the manifesto, and even the Responding to Change value. This is the kind of project that Agile methods are built for. There is a lot of overhead in a classic project which has been done already when the software was initially created. skipping that overhead and rapidly moving forward with a small team to deliver this new value in as short of a time-frame as practical would not only provide more value for the user, but for the organization as well.

How would an organization even create this big new project to enhance and bug fix a released piece of software? When would requirements gathering be sufficient to launch the project? What do the users do in the interim while the project is running? What if they find more, and more important issues after it kicks off?

Treating this maintenance period as an Agile project instead of a classic project, even in an organization not usually doing agile, may be the better answer. There are organizations which are still doing software development in a non-agile way. Some of them may have external constraints that make sure the project operates in a stage-gate manner. Perhaps they are struggling to figure out a way to bring agile methods in for better value. The answer for such an organization might just be the maintenance period. In fact, they may already run maintenance in a fashion that would look familiar to many agile enthusiasts.