Midwest IT Survival

If you are looking for the most straight forward, pragmatic book covering the most prevalent Agile software development approach, then “Essential Scrum: A Practical Guide to the Most Popular Agile Process” by Kenneth S. Rubin (Amazon link) is it. From beginning to end, the book walks you through all of the concepts and techniques that makes Agile Scrum software development as effective as the industry has recognized. My only regret is that this book wasn’t available a hand full of years ago when I was fumbling my way through implementing Agile methodologies when I was leading development teams.

Disclaimer: I was privileged to assist the author, Kenny, with reviewing sections of the book prior publication. Kenny was gracious enough to mention my contribution in the Acknowledgements section of the book.

Kenny has structured the book to be a classic chapter by chapter read. Chapter 2 provides an excellent end-to-send Scrum primer with chapters 3 through 8 addressing the core concepts. Chapters 9 through 13 cover the roles of product owner, ScrumMaster, etc. Chapters 14 through 18 address planning including more complicated topics such as multi-level and portfolio planning. Chapters 19 through 22 cover the sprint in depth. Chapter 23 ends the book with the send off: “There is No End State” and re-iterates the lack of a one-size-fits-all mandate with Scrum. The chapter sequencing serves as both a comprehensive education on Scrum as well as an excellent concept reference when your team is struggling and a specific Scrum technique needs to be re-evaluated.

To all of those looking for a single text to provide the most breath and depth of coverage on the Agile Scrum methodology, I strongly recommend Kenny’s book. After only being published a few weeks, Jurgen Appelo listed it at 76 on his Top 100 Agile Books (Edition 2012).

Today's IT Projects Need Transparency to Change

For large organizations it seems that as technology grows more and more integrated, IT related projects become more complex and thus longer in overall duration. There is no doubt the rise in cloud/SaaS solutions has exacerbated this increase in overall IT project complexity. I’ve written on the impact of cloud in this manner prior here. Gone are the days of a large corporate IT shop having a project manager engage the same three or four familiar delivery stakeholders and with little outside involvement, execute the project beginning to end. This increase in technical integration means a project manager can no longer count on those three or four stakeholders having the cross systems knowledge and technical systems access to implement changes as crisply with few artifacts as to what the project has done/is doing/when/etc.

To help illustrate this evolving shift, consider the following hypothetical large corporate IT conversation:

PM: “Welcome everyone to the FlimFlam upgrade project’s twentieth weekly status meeting and a special welcome to Jim who is joining to help sort out all the changes that impact others outside of our core team.”

<General welcoming gestures and verbal niceties ensue>

Jim: “Ok, is there any diagram that captures all the flows of data in and out of the current FlimFlam system?”

Core Team: “Um, no, we just know them from working on FlimFlam for the last five years.”

Jim: “Um, ok, have you mapped out what new features of the upgrade are turned on compared to off and who would be affected? Or say, documented the link between the features and business requirements?”

Core Team: “Well, not documented, but we know HR wants the real-time instead of batch interaction and Operations wants better reports. But HR outsourced last year to a cloud provider and we have no idea what Operations is doing …”

Jim: <thinking to himself> “… oh boy, good people, but this project is looking like a train wreck already …”

Clearly a “business as usual” approach to this upgrade isn’t going to work any more.

In the past, with so few stakeholders having comprehensive access to the silo-ed systems impacted by these types of changes, the need for easy to digest transparency into what changes were going to happen when and how was not critical. Sometimes the only visibility to what such a small project team was doing was in the production change management review and approval process:

Change Control Board: “Ok, next up is change record number 72,578 which reads ‘Enable the employee web portal to support the time off calendar’. Anyone here have any concerns with this change? Hearing none, approved. Next on the list …

Today’s Problem: IT systems are too interconnected for lack of project transparency to change

Sounds like 72,578 is a simple change that an HR delivery team of the past could have easily implemented without much cross team impact. But today, that example time off calendar may need to interact with the HR system to record those time off days against how many the employee actually has as part of their compensation package. There probably is a need to support some management approval work-flow. Plus, there are probably other work scheduling systems and PMO resource planning tools that need a feed of that data in order to accurately support their user base. There is probably some single sign on/web access management technology involved to support all employees accessing the web portal, some central provisioning system to handle access plus some remote access needs to support today’s mobile workforce. It is probably safe to assume that some of those integrated systems are in-house and some are cloud/SaaS or a mix of all of the above.

Additionally, with matrix-ed internal and external project resources with contracted and off-shore delivery coupled with the “cloud” vendor resource engagement model, a simple change could have a variety of stakeholders in need of agreement on what is changing when, etc.

Thus, hopefully I’ve convinced you that something as simple as a web portal for employee time off entry can involve a number of different internal and external teams and systems that all need to coordinate changes to support the business objectives of this example project.

So how does this all drive the need for “transparency”? Isn’t this just a basic PMO 101 issue of dependency management and cross project impacts?

Yes and No

The project team needs to produce deliverables that don’t just get the core team in agreement to pass the next quality gate in the project life-cycle (never to be revised again); the project team needs to produce deliverables that outline, at a high-level, the following basic project elements:

• Scope of the project in a sentence or two
• What is changing from present to future state
• Who is impacted by the change (and have they been engaged)
• Lastly, what isn’t in scope (that a non-core stakeholder might assume is in scope)

… for non-core stakeholders to easily digest and understand … and update the material frequently to have at the ready anytime it might be needed.

Besides an effective communications vehicle, another subtle yet important aspect to this deliverable is its ability to build confidence in the effective management of your project in outside stakeholders. This confidence can lead to senior management getting the impression the project is “under control” and move on to another project for increased scrutiny rather than assigning all kinds of ancillary people to dig into your project to figure out why they don’t have that “under control” feeling.

Stated another way, large corporate IT projects today need to adopt a bit of “program management”, specifically, some of the enterprise reporting themes. A Gantt chart (which I’ve extolled the benefits of before here) isn’t the end-all-be-all here. A slide deck that contains a few slides covering these topics with lots of pictures and drawings where ever possible would be more effective in serving this communication need.

So if you are a project sponsor or a project manager, consider having a communication deliverable that is actively maintained, even if your PMO PLC doesn’t explicitly call for one, to provide simple and easy to digest transparency into key aspects of your project at the ready at all

The challenge to integrate Architecture and Agile

Recently on Simon Brown’s blog “Coding the Architecture”, Simon posed are interesting challenge of which this article provides my response. I enjoy Simon’s blog for he presents very well thought out articles on the challenging overlap between Agile software development and the value of architectural principles in providing software solutions. As those that frequent my blog have seen, I’ve written about the challenges of integrating pure Agile development methodologies into non-Agile organizations such as legal services, manufacturing as well as financial services. I’ve approached the topic of work estimation here which is a frequent challenge in non-agile organizations that make project and resource prioritization decisions based loosely on the estimated work effort. I’ve tried to successfully blend Agile story and blacklog project management with the preponderance for waterfall-esk program management here. Based on the comments to that article I didn’t succeed in my goal. I’ve even broached the Agile versus architecture question before here but the focus was on the Agile reducing over architect-ed solutions rather than taking Agile versus architecture head on. I’ve even discussed budget challenges before.

Simon’s challenge: Given a four month window to deliver a new software project in an Agile shop, how would one go about doing so given some interesting constraints? The below graphic is from his blog post that captures the unique constraints for this challenge:

Based on my multiple years in the financial services industry working for more than one bank, I feel the need to outline some immediate assumptions that pop into my mind that are tainted by my direct banking experience:

1. Design Firms – Simon’s challenge involves the bank undergoing a new branding effort. In my experience, a bank’s internal marketing department partners heavily with an outside marketing firm for larger banding initiatives. Additionally, new branding efforts usually involve getting that new brand message out through a variety of channels.
2. Middle-ware/SOA capability – Given the overall growing maturity in the service oriented architecture space and the relative IT budgets of most financial institutions, I am going to assume there is some middle-ware, messaging and/or enterprise service bus-like capability to leverage.
3. Content Management System/CMS – Given the explanation of the current state online banking system, I am going to assume the bank does not currently have a mature content management platform which can be extended to provide online banking functionality.
4. Backoffice – Also, I am assuming that the bank currently has a backoffice transaction system that currently performs the bank’s core bank product transaction needs. For the sake of this exercise, a “legacy” mainframe set of applications are in place that run the core bank transactional services that has some capability to expose those transactions to the middle-ware/SOA platform.
5. Build versus Buy – A classic challenge for banks has been the decision to put the focus on building in-house capabilities versus buying mature vendor solutions and integrating those into the technology portfolio. Depending on the financial health of the bank itself as well as the predilection of the CIO, the build versus buy pendulum can swing to either extreme. Add the frequent turn over of senior IT leadership and this can be a real challenge for enterprise architectural patterns. For the sake of this exercise, the assumption is that the bank is willing to invest in the middle-ware transactional capabilities in-house as well as the supporting online banking application user experience but prefers to purchase a new content management solution to host the UI.
6. Big Bang versus Functional Sequence based rollout – I am also assuming product management is risk adverse and open to sequencing in the new functionality rather than demanding a big bang approach. More on the sequencing later in this post.

Given the architecturally significant changes requested in 4 months, specifically the read-only to real-time transactions and the complete hosting re-platform need, I would convince management that it would be infeasible to deliver everything in 4 months. Yes, the project management side of my brain says don’t over commit given the technical complexity involved and the linkage to a significant customer impacting change.

Thus convinced, I would then break the effort into multiple parallel technical efforts:

Re-brand current site = I would spin up an Agile team including the online banking product management/manager to focus on re-branding the current site between now and the 4 month end date. The team’s priority would be:

1. Integrate the new branding into the current site working heavily with the outside design firm
2. Make changes, assuming no conflict with #1 above, to improve W3C compliance

Create re-useable transaction services = I would spin up another Agile team that has the mission of exposing the backoffice transactional services as “enterprise” consumable web services through the middle-ware platform. The stories would mix both the technical needs such as “Develop a way for the middle-ware components to authenticate to the mainframe components” as well as business capabilities “have the ability to transfer unlimited funds, subject to current available account balances, from one customer owned account to another account owned by the same customer”. The prioritization of the stories would be as follows:

1. Architecturally needed stories such as component to component authentication, high availability, etc. Basically, everything needed to support #2 below.
2. Transactions needed in the new online banking product based on the roll-out schedule.

One of the challenges for this team is the likelihood that the mainframe platform participants are not familiar with Agile practices. Thus, extra coaching is probably a must for this team.

Purchase Content Management Product = I would task the architecture group to work with procurement to select a vendor’s content management product that will become the framework for the new transactional customer user experience. The classic steps would be undertaken: RFI/RFP, product evaluation, proof of concept, vendor pricing negotiations and ultimately product selection. This needs to be completed in enough time for the next team to be able to deliver some functionality in the new CMS product.

New UI Development = Finally, I would spin up another Agile team to map out and build the new transactional UI. Their first challenge would be to reverse engineer the customer authentication system to determine how the system authenticates users and then links them to their accounts and products with the bank. They would need to work closely with the re-branding Agile team to determine the most seamless way to add navigation to the current site to link over to the new site for the real-time transactional capabilities. Additionally, this team would also have to work with the middle-ware team in order to understand the re-usable services being created and how to consume them. Lastly, this team would also have to keep tabs on the content management team to follow the procurement process and start to understand the framework capabilities of the new CMS product and how to link those to the navigational needs and transactional needs of the final online banking product.

This last team would have a heavy architectural staffing up front and transition to a more development heavy staffing towards the end for delivery. In a perfect world, the project management resources from this team would be the most senior in the organization and consistently work with this team as the skill-set transition occurs.

The below Gantt chart reflects the multiple parallel efforts and when they ultimately need to come together to deliver the final product.

The functional roll-outs would be linked to the customer marketing campaign in order to provide sequential customer communication on new product features as well as permit the new technology “kinks” to be addressed. Also, this allows call centers to ramp up temporary staff to address the increased call volume due to the changes impacting customers familiar with the prior system.

The actual sequence would need to be agreed upon by IT, product and call center management, but potentially the following sequence might fly:

1. Launch the old site with the new branding.
2. After a brief window of time to let the call center call volume return to normal levels, replace the link to current “account balance” information in the read-only system to the same “page” in the new system that requests that same balance through the new middle-ware services. The customer experience would be marginally impacted in that instead of seeing yesterday’s balance details they would be seeing their current account balances. Lastly, address any negative performance or functional kinks.
3. Add account transfer links to the old site that take users to the new site to perform the transactions [first real new customer functionality]
4. Same call center pause.
5. Repeat the sequence for additional transactions such as external account-to-account, bill payment, bill presentment, etc.
6. When all transactions are being handled both UI and middle-ware by the new site and the old site is essentially a set of static pages with links, cut the login process over to the new new site and disable the old site when web logs show no stray bookmarked pages are being accessed. Porting over the authentication system was part of the deliverables of the third Agile team.

Sure, this sounds like a full program of interdependent project activities, but from my experience, banks want to provide highly available and reliable services to their online customers which tend to be their highest revenue generating customers as well. Thus, all of the incremental functional roll-outs which come with the additional cost of testing and program management overhead deliver on the risk adverse, reliable and measured change.

I look forward to all the alternative approaches to this challenges Simon has presented. How far am I from the response norm? Any fundamental flaws?

We need these ten changes implemented ASAP!

There never seems to be an end in IT, particularly in corporate IT, to balancing competing priorities in the form of seemingly endless work requests.  How many times have you been involved in this typical conversation?

Business: We need these 10 changes implemented as part of this project.

IT: Ok, you put that project on hold a few months back, but we can dust off those 10 changes and get working on them.

Business: How long is it going to take?  Before we put the project on hold it was supposed to take one month of development.

IT: Yes, but a number of other projects have changed the systems involved since the project was put on hold.  We will need to do some analysis and get back to you.

Business: <reluctantly> Ok.

<Analysis occurs amongst technical people and a whiteboard>

IT: In order to meet all 10 requirements, it is going to take two months of development.

Business: What?!?!  Before it was going to take a month, now two months, why double?

IT: Well, because of the FlimFlam upgrade project, we need to rework two of the interfaces in order to meet requirement number 7.

Business: Without requirement number 7, how long would it take?

IT: We’ll need to go back and rework the estimate because the development effort involves meeting requirement number 7.

Business: <clearly frustrated> Ok.

<Re-analysis occurs amongst technical people and a whiteboard to remove requirement #7>

IT: Ok, without requirement number 7, it should only take three weeks.

By this time, all project stakeholders are frustrated with each other.  Tension amongst everyone is high and any misstep going forward has the potential to erupt into a finger point/blame session over tiny deviations from the plan.

Is there anything that can be done to avoid this repetitive negative pattern?

Sure, just implement one of the Agile or Lean methodologies and all your problems go away.  Continuing to use the Waterfall methodology will place you in this situation time and time again.

But what if your organization, as a whole, is not in a position to implement anything but something akin to Waterfall?

One of the major challenges for any manager of project delivery focused resources is project sponsor expectations management.  Unless you are blessed with a very strong project management office, you are most likely stuck with this loathsome duty to some extent.

In your typical corporate project delivery structure, IT is resource constrained compared to all of the work the project sponsors desire.  There exists some process function to try and prioritize the work in some manner (by ROI, revenue generated by business unit, charge back mechanism, etc.)  Even with all this in place, you still have aggressive project sponsors that are trying to keep their goals and objectives marching forward at all costs.  Some partner well with IT.  Some, well, are ever so difficult to keep satisfied.

I can’t say I’ve found the silver bullet that makes the challenges of project sponsors evaporate, but I have found some techniques to reduce the frustration:

Overly communicate on project priority changes

When you find your team members re-directed due to a shift in the priority of projects, take the extra step to remind each project sponsor of the “cost” of this change:

“I just wanted to share that due to the corporate priority committee indicating that the FlimFlam Upgrade project now takes top priority over your project.  Due to this action, any communicated delivery dates for your project are now no longer valid.  Also, since technology will likely change as a result of this shift in priority, your project will need to incur additional time in order to re-evaluate the technical solution and then new dates estimated.”

Don’t assume the project managers will update their project sponsors.

Communicate cross-project impacts regardless of sponsorship

More than likely, your team is a shared pool of resources that is assigned to a variety of projects.  Expecting your project management function to keep track of your resource contentions is hoping against hope.  You are relegated to keeping track of who is working on what for whom and all of the interdependencies between projects. As one project plan gets turned to mush with changing requirements or delays on the business side, feel free to pass that information on to the projects that you team member is also assigned.  Unless you own the project management function, don’t assume the project managers are sharing this type of resource conflict information cross-project.

Communicate Work Breakdowns with Schedules

When working with your team to communicated major dates back to project teams, in additional to communicating estimated delivery dates, also attach work breakdown structures to go along with those estimates.  Make sure to include all possible (realistic) information that might be stressors on making those dates.  You may also want to consider projecting out the work schedule over a calendar.  This way you can add in buffers to handle all of events and activities that cause people to get distracted from focusing on their project work.  I’ve written before about considering a 5 or 6 hour productive work day for your team members.  Or if your team member has an additional assignment to learn new technology or do some cross-training with another team member, factor time for that work into the project work schedule.  A 10 hour blob of work for a given resource may need to be started on a specific Monday and not actually be completed by the end of the day the Friday of that same week.

These considerations are far from guaranteeing a stress free existence for your delivery focused team.  Rather, with enough re-enforcement of the detractors that impact your shared resources from being true dedicated project team members, project sponsors shouldn’t be lacking for information.  This information should reduce the potential for what I call the “surprised and confused” reaction and allow you to focus on your team’s real goal: delivering solid, working technical solutions that meet the project requirements.

Everyone participates in iteration planning meetings

Today is the third and final day of the Agile Boot Camp being hosted by ASPE SDLC Training. I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery. I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy. In order to appreciate this article, I suggest you read my thoughts and experiences from the first and second days.

First, the excellent Davisbase, LLC instructor finally revealed his contact information. I confirmed with him it was ok to share so here goes:

Rod Ashton

rod@davisbase.org

801-918-4092

I can’t stress enough that Rod’s real world experience in corporate IT project rescue and his on premise company Agile consulting experience were extremely valuable to making this course very pragmatic. Rod would physically step from the center of the room (Agile practice, process and theory) to his immediate left (real world) frequently to segue from theory to practical real world experience based guidance. This made the course triple in value for me. Lastly, at the end of the day today on the course feedback sheet, the best I could come up with on “needs improvement” was having white-boards for team exercises.

The third day is where everything really came together. Thus, without much lead in, here are my bullet point notes from the day:

• When asking why, consider 5 level of “why’s” to get to the bottom of the real need
• For developers that are stuck or struggling to break down a blob of work into tasks, lead them through their internal thought process of developing the blob with “what are you doing to do first? What are your going to do next? Next? Next? …”
• For product folks having trouble articulating what they really are asking for, try “if you could wave a magic wand, what would you want?” to break the potential log jam of real world constraints and competing priorities to get them to spill.
• Make all changes in small increments in order to “tweak” the output in order to achieve cadence.
• Always, rule of thumb = “simplicity”
• Considering the above two bullets, start with 2 week duration iterations in order to get feedback sooner and see results of incremental changes sooner.
• Agile plus continuous integration maybe the next hot thing in efficient and effective software development.
• To start to build team commitment, PM or Agile Coach or Scrum Master lock eyes with team members to get personal commitment on initial story execution until team auto-commits by default.
• No brainer, but how many organizations are realistic on capacity? 6 hours a day max on average of real employee productivity.
• Everyone, everyone, everyone involved in an iteration participates in iteration planning.

I captured some helpful tips on how to establish a new team’s initial velocity:

• Plan to do the hardest stuff first
  • Tolerance for mistakes from management, nay saying peers and others are higher initially and less so as time marches on.
• Time box one hour for estimating to encourage quick decisions and less conversational off topic drift.

All in all, it was a lot of material crammed into three days. Rod did a great job keeping the class moving and keeping attendees awake and engaged. Plus, as I said before, his real world experiences merged with the Agile principles and process really made the course outstanding.

Now, my challenge is bring all this knowledge into practical execution with multiple agile and non-agile development teams plus non-agile infrastructure and all the classic corporate IT structures.

Can you really multitask?

Today is the second of a three day Agile Boot Camp being hosted by ASPE SDLC Training.  I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery.  I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy.  In order to appreciate this article, I suggest you read my thoughts and experiences from the first day.

With the basics of the history and the initial ground rules out of the way, now the class can dig into the meat of Agile.  The instructor started the second day with an interesting exercise. We were asked to do three things, each time boxed to two minutes:

On a piece of 8.5 x 11 regular white paper, do the following (2 minutes each):

• Write as many numbers as you can, 1, 2, 3, 4+
• Write as many letters of the alphabet as you can.  When you reach Z, start again with A
• Write as many letters and numbers as you can: A1, B2, C3, D4+

At the end of each 2 minute writing exercise, he captured the top number of entries from the class.  What was interesting and the point of the exercise: no one did particularly well on the letters and numbers exercise.  Even the clever people that tried various techniques to write faster failed to write as many entries as either numbers or letters only.

The point = people can’t multi-task as effectively as they think they can.

Or as I’ve come to appreciate this topic:

Context switching has a price.  That price can be around a 20% loss of productivity as a whole when someone is assigned an additional concurrent task to complete.

Many, many articles support my statement above. One classic is Joel Splosky’s “Human Task Switches Considered Harmful”

Early in the day, someone asked the instructor to share his opinion on if a team commits 100% to start being Agile, how long should it take to go from starting with high frustration to running smooth with little to no frustration.  Mind you, this is just his experience seeing companies and teams take on Agile, but in his opinion:

New Agile Team, 100% dedicated resources = 12 weeks or approximately 6 iterations

New Agile Team working with a vendor = 24 weeks or approximately 12 iterations

New Agile Team + vendor + contractor(s) = 36 weeks or 18 iterations

In more Agile terms, the project team requires the durations above in order to have more of a constant/predictive velocity and established cadence.

It was striking to see how the external elements of vendors and contractors double and triple the time it takes for a team to achieve a predictive Agile rhythm.

As we learned about good story creation and planning poker and relative estimating, I jotted down some Agile success themes that struck me throughout the day:

• Product Roadmap creation forces collaboration amongst all stakeholders.
• Serious Agile success is achieved when the business starts asking how to use Agile for their business work to be as productive as IT.
• Stories are from the user perspective, who, what and why … if you can’t define the “who”, then stop all work/discussion on that story.
• Agile requires a culture that encourages everyone to ask questions of everything
• Stories can come from anyone on the team … developer has an interesting idea about a product feature?  Write up a story for the backlog.

One of the more challenging topics to get ones waterfall head around was the planning poker or story estimating.  I wasn’t alone, a number of technical folks were asking questions around how it is possible to say this work takes “8 units” without completing that phase with “ of hours/days/weeks”.  Most classic corporate IT budgeting and projects need estimates of actual X features completed by Y.  Agile works under more of a “line of credit” concept stating: given Y amount of time and Z resources, X features will most likely get done assuming some velocity with cadence achieved.  I’ve tried to capture this challenge in more detail in this previous post on “Agile versus Classic IT Budgeting”.  For many classic corporate IT shops, this is a huge cultural challenge to overcome.

I am looking forward to getting back together tomorrow for the final day of talking about how to slot in stories based on priority and work units against the roadmap as well as release planning.

Demo Early, Demo Often?

Today is the first of a three day Agile Boot Camp being hosted by ASPE SDLC Training.  I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery.  I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy.

The first day covers the history and an introduction to Agile.  It also covers the forming of Agile teams, creating the product vision, focusing on the customer and the product road map.  The instructor was a little slow to get going, but once he got past the high level introductions and the brief history of Agile, things started to move quicker and get more interesting.  The class is full of people from all industries and job roles.  There are people from manufacturing, health care, insurance, government, consulting and financial services.  There are developers, managers, business analysts and project managers.  The class is mostly people without much if any Agile experience, so the pace of the course is perfect for the majority of the attendees.  Given my personal research and light weight implementation of a hybrid of Agile principles in past professional lives, I could see the course moving through material and concepts much quicker.

The instructor had us split into three and four person teams to do some exercises that support the content of the course.  Each team is given some very loosely defined requirements such as make paper airplanes that can achieve a certain goal or organize a pile of colored paperclips.  Once the exercises are completed, the instructor reveals the Agile specific principles involved in the particular activity.  This teaching technique is a creative way to get introduced to the theory before actually being told that theory from a strictly academic sense.  In the examples of the paper airplanes, team members self-organized into airplane designers, developers and testers based on the ad hoc team members basic personal/professional strengths.  I was amazed my high school mentally distracting interest in creative paper airplane construction coupled with the CWRU Strosacker quest to make paper airplanes glide gently over the crowd to softly bump into the main screen to the gleeful cheers of the students in the audience that came in handy today.

After today’s session, in chatting with the instructor, I learned he is a 25+ year veteran of globetrotting in order to rescue projects that are in trouble for time and/or budget reasons for American Express and other multi-national firms.  His hands on real world corporate and consulting experience gave additional credibility to the course material.  Some of his helpful, but maybe not strictly textbook knowledge shared included:

• Demo early, demo often = don’t wait till the end of the Scrum sprint to demo the product increment.  Get feedback ASAP in order to handle possible course correction.
• Team best practices =  Open and Honest Feedback = Direct, Specific and Non-punishing
• Plans are useless, planning is indispensable.
• Documentation is required, but only to the lowest level necessary.  “Do what it takes to barely get by”

I am looking forward to getting back together tomorrow to talk about creating and maintaining a product backlog, prioritizing that backlog and estimating work plus release planning.

How to marry the classic IT budget and Agile?

I’ve been reading more and more about managing large projects with Agile.  I am wondering how best to optimize the merger of the classic IT yearly budget cycle for large scale projects with the Agile principles and agile project delivery.  There has to be a way to balance the constraints of an upfront budget process with the benefits of agile-ly deployed business prioritized deliverables.  Or in other words, how does one keep the dollars and cents focused people happy and the business project sponsors enjoying the benefits of Agile delivery?

The classic IT yearly budget cycle I’m referring to is one of wild guesses at capital such as servers or software licenses, maintenance, expense and internal plus external resource costs to complete projects that involve IT in the next yearly financial calendar.  Projects maybe completely IT driven with IT as the end customer or projects maybe requested by the business to deliver business value that need IT support in delivering that value.  In either case, the classic budgeting versus agility challenges is the same.  Take the typical project mixing IT and business changes:

New Project Request Form:

Project: A456 Enable Call Center Order Confirmation

Scope: Upgrade the FlimFlam call center system from 5.0 to 6.0 to enable the customer communication widget and change the call center workflow to use the widget and not carrier pigeon to confirm orders with customers.

Budget Questions:

• How much does the upgrade cost?  (easy, ask software vendor)
• How many consulting hours and dollars are needed to support upgrade? (medium, ask software vendor’s professional services for a typical customer upgrade number, then add fudge factors to map over to your company)
• How many hours from your internal shared IT resources to support the entire effort? (hard, don’t have the time to go through the project requirements gathering and design phase or collect all stories, get story points, etc., etc., so take a wild guess based on past projects or other similar work, add fudge factors, add more fudge factors, then double it … you get the idea)

Project Budget Submission Criteria:

? = Capital

? = Maintenance

? = Expense

? = Internal Resource Hours

? = External Resources Hours

? = External Resources Hourly Rate

? = Total External Labor Costs

The budget process demands a number to be provided for each question mark.  You know that certain magic number thresholds, if cross, will doom your project or almost as bad, push it into a category that requires a whole new level of business case and ROI sizing effort. This classic IT project budgeting process doesn’t seem to support the majority of the Agile project delivery process.

Does anyone have any experience or references to best practices in this area of marring legacy budgeting and agility?

Get too tactical and get set on fire

I read Neil’s “How to do Nothing” blog article on the topic of effective management back when I first discovered his blog earlier this year (2010).  I was struck by the pure simplicity of his eight attributes of effective team management at the time.  Neil was gracious enough to comment on a recent article I published on agile project management reducing application over architecture.  I went back and re-read his article and realized it is even more impactful on successful team management than I originally thought.  I thought I would take a few paragraphs to further extend the concepts Neil outlined in this article.

Anticipate rather than react

Neil suggests having your hair on proverbial fire frequently by getting hands-on in addressing issues isn’t the most affective approach.  I agree with him that in these hair-on-fire situations, it can be exhilarating to roll-up your sleeves and jump in and be the hero that saves the project or restores production service, etc.  Once a sense of calm returns after the hero has saved the day, the hero starts itching for the next crisis to be the savior and the behavior gets repeated.  The hero may get initial fame and glory, but it is short lived.  In my experience in multiple MidWestern companies, the hero ultimately gets revealed for his/her display of reactionary management.  Senior management begins to grow tired of the peaks and valleys of crisis, pending doom, disaster avoided, pause and repeat for the next crisis.  I’ve also seen the hero scratch their heads when the next re-organization comes along and the hero finds him/herself as a technical lead over a team with a new management layer above them.

Maintain relationships outside the team

I definitely agree with Neil here.  I would even add the larger the organization, the more this is essential.  As your team provides a service to a larger project or effort, the number of ways other teams can throw a wrench in the works is almost immeasurable.  In addition, the message that gets filtered to your team and then to you may be completely disconnected from the real blockage.  Being able to pick up the phone and call a peer manager, with whom you have established a rapport, and get right to the real issue is invaluable.  Once the real issue is known, you can offer guidance to your team on how to navigate to a successful path forward.  Without this knowledge gleaned from a peer manager, you can easily get caught up in the panic the blockage creates and risk being set on fire in the process.

Big visible task boards

In a word: absolutely!  By all means, assuming everyone knows what to do is a recipe for disaster.  A disaster in a sense that tasks won’t get executed according to plan and you will be dragged back into strategizing on how to go forward while accounting for the missteps of the past.  As Neil says, use a whiteboard or in my case, use some electronic task tracking system that isn’t overly cumbersome yet makes it unbelievably clear who is working on what, doing what and when.  Have you ever considered using your bug or defect tracking system as a light weight task tracking mechanism?

Team collaboration

I’ve written on this topic in the past relative to the leveraging of self-organizing, strong teams with a focus on intense collaboration.  If you make yourself a keeper of all knowledge, you will constantly be engaged to assist with tactical decision-ing and thus at risk of again, being set on fire.  If you drive team members asking you questions back to fellow team members, they will start going to fellow team members directly.  Clearly, once this occurs, you will need to be contingent of when you will need to specifically instruct your team to collaborate with you when you are engaged in some issue that you aren’t at a point of delegating just yet.

Small incremental changes

If you are considering pitching or implementing a significant change that you have dreamed up that will get everyone working better, more efficient and at the same time cure cancer, you might want to put on the brakes.  People accept change in a variety of ways.  The more aggressive the change from the current norm the more likely you will have to invest additional time in addressing how each impacted individual reacts to the change.  If you stretch your change implementation out over time so it seems like you are providing “just in time” solutions to the ultimate problem, you will most likely achieve a more successful end result all around.  Plus, with each incremental small change, you can more easily course correct or tweak your next change to be even more effective and hopefully, even less visible.

Inspect and adapt

Getting the team to contribute ideas and suggest process improvements takes the decision-ing pressure off of you and empowers the people doing the work and most impacted by the process to suggest the most effective improvements.  Plus, if the team is on board with an improvement, they are more than likely to make the implementation successful, because it is their improvement.  On the flip side, how motivated are you if you have the ultimate “my boss told me to do it, thus if it doesn’t work, not mu problem” excuse at the ready when the slightest problem is encountered?  What motivation does anyone have in that situation to try and make it work?

Hire great people

These almost goes without saying … hire great people and then just get out of their way so they can do good work.

Commit to personal development

If don’t have the flexibility to move poor performers out and attract in top performers, and let’s face it, MidWestern companies don’t always have the most flexible staffing models nor the local talent pool to quickly make team changes happen.  Bringing up the level of your current team is more than likely your best option.  Take advantage of any tuition or training bugets available to strongly encourage folks to get away from their desks and get exposed to some additional improvement perspectives.  Consider incremental “stretch” assignments to use as opportunitties to challenge those that have a weakness in a certain skill set.  Catch up with them “offline” and chat with them about what problems or challenges they are facing and offer some tips to help them get over those hurrdles.

Summary

In summary, the concept that a strong manager is precieved to be “doing nothing” is a compelling goal for any team manager to attain.  By essentially making it a top priority for you to empower your team to function as autonomously as possible, it allows you to focus on inter-company relationship building and other functions only you can do.  It also allows you to identifying process and skill set weaknesses without being tactically involved in the work to consider small, incremental improvements and then absorb the result.

Don't give up on the Gantt!

I’ve written before that I am not an “Agile” nor “agile” development nor project management expert. I’ve previously proposed that one by product of “agile” development and project management in general is a reduction in over architect-ed software solutions. With project requirements being represented as stories and tools such as Kanban boards for lean software development to show the flow of work through a process, one might think the classic waterfall project management work and schedule reporting tool, the Gantt chart, is obsolete. Before you abandon this tried and true project schedule reporting solution for the more transparent status inherent in agile project management, you may want to keep reading.

So, you have succeeded in transitioning your IT project management and delivery methodology to one that is more aligned with “agile” than “waterfall”. Your non-IT stakeholders are more engaged than ever in the project requirements definition, prioritization and sprint/release scheduling process. You are tempted to stop trying to use MS Project or other tools to represent schedules in Gantt form. In a word: “don’t”.

One of the main criticisms of complete agile project management is: “The dangers are the loss of recognition that systems/solutions change continually over time as well as team members” Put in more direct, bullet point form from my experience of this criticism expressed by product or management stakeholders:

• What is the big picture?

• I have the big picture in mind, when am I going to get X?

• At the current burn rate, how much time will be invested before I get Y?

• If I add/subtract resources, what will be the impact on the big picture?

These are all criticism subsets that can be directly addressed with the data collection associated with producing a classic Gantt chart. So don’t throw away those Gantt chart creation disciplines just yet.

What is the big picture? I have the big picture in mind, when am I going to get X?

Let the sprint/release iterations continue, but don’t let too much time go by past the releases to meet with the product stakeholders and update your rendition of the product road-map. (You have your road-map, right? You aren’t letting the business surprise you with all requests, right?) This is a great opportunity to get an early indicator if product stakeholders have become caught up in their immediate needs and lost sight of the “cost” of those features. By “cost” I mean the investment in features now means pushing out the product road map. You can gently remind them how the “cost” appears graphically in a Gantt. The Gantt view of their product can clearly show “milestone 45” getting pushed into the next quarter due to their recent feature bonanza. It is much easier to have the “hey, I thought I was getting milestone 45 this quarter” discussion as soon as the schedule shows initial signs of slippage rather then at the start of the next quarter.

At the current burn rate, how much time will be invested before I get Y? If I add/subtract resources, what will be the impact on the big picture?

Here again is where your mastery of tools such as MS Project and the Gantt chart view of the product road map are exceedingly important. If you are working for a MidWestern company, rather than say, a start-up, you can’t ignore traditional budget and resource management constraints. As a start-up in growth mode, your focus is getting your product out the door with the resources you have or your resources plus the on boarding of additional resources. In a MidWestern company, you are most likely trying to maximize the resources you have or being asked to reduce your head count while still meeting project expectations. Thus, prioritizing features to be delivered against a shrinking resource pool is a given. You need something beyond the agile sprints/releases under way to manage project stakeholder expectations on what can be accomplished when.

The Gantt view of the work allows for a graphical view of “if this is more important, what else is impacted” realities. Additionally, add in the need to manage a fixed pool of resources across multiple agile projects and you absolutely have to have some way to represent a view of the prioritized work across all resources. In addition, you may need additional tools to help represent the “what if our team member Sally gets assigned to the VP’s ‘special project’, what does that do to our resource model and what can get done when?”

Conclusion

As an IT manager or IT project lead in a MidWestern company that is moving towards more agile project management and technology delivery, you may be tempted to relax the project management disciplines that come with the more traditional waterfall approach, specifically tracking project schedules in a Gantt chart. In order to avoid the inevitable product stakeholder expectation mismatches as well as pending budget cutbacks and/or uncontrollable resource re-allocations, keep collecting that “program management” data. Continue to have re-occurring meetings to review the “big picture” Gantt chart view of the work and use other tools to reflect “what if” scenarios and their impact on the big picture.