Imagine 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.
I’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. Continue reading
I 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.
The first listed principle at agilemanifesto.org lists customer satisfaction via delivery of valuable software as the highest priority.
Stoonn – freedigitalphotos.net
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. Continue reading
I 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.
Despite 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. Continue reading
While 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.
It’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.
Often 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.
When 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. Continue reading