Welcome to Agile Colony. These are my thoughts, opinions, experience and viewpoints about Leadership, Corporate Culture, Agile Software frameworks, Technology Trends and other various aspects of Business Technology.
Catching Elephant is a theme by Andy Taylor
Annual Budgeting and Agile IT, Part II: Why Agile Gets Compromised When It Goes Corporate
From: The Agile Manager (Ross Pettit)
In corporate IT, the CFO isn’t trying to solve a “make better use of capital” problem in the business. He or she is trying to solve a “consistent cash flow from operations to service our capital obligations” problem. When Agile goes corporate, it is subservient to, and most often compromised by, that latter problem.
Agile, when all else fails, “Just Stand Up”
If you don’t have the luxury of working for a true, agile organization or you are struggling with an agile transformation from predictive methodologies, take a huge step back and focus on one tenant of agility; the Daily Stand Up Meeting.
So many companies (especially larger firms) fail to incorporate agile in their I.T. departments because it requires such a broad change in thinking, style and execution. Asking hundreds of developers, testers and especially management to make these changes is difficult. So much buy-in is required across larger corporations that what tends to happen is that an I.T. department will have a certain percentage of people using agile and the rest resisting passively or actively by using more traditional delivery methods. No harm, no foul, change is hard.
So take another route. Just ask every project team to use the short, daily stand up meeting used by all agile frameworks. I suggest this because the stand up meeting is cheap, easy, quick and within days, makes total sense to all participants. It makes sense because people realize quickly that for a minimal effort on their part, the team generates a massive amount of daily “group intelligence” for the project. Everyone knows what every team member is working on and what they will do next. The entire team knows the constraints and the gravity issues immediately, every day.
This one tenant of agile is so basic, so simplistic in design, yet yields so much data to project managers and upper management who participate.
If you’re struggling in “big corporate” with agile, don’t use a hammer, just allow people to find their own way with agile practices that help all types of project management styles without labeling it, “agile”. Sometimes the word “agile” is polarizing. Let this one, common sense meeting do all the talking for you. You’ll be amazed how quickly you see stand up meetings popping up around your company and your coworkers will have that “ah ha” moment on their own.
The Agile Stand Up Meeting - common sense, easy to do, lots to gain.
PMI Further Embraces Agile
It’s not breaking news that the PMI has been embracing Agile over the last few years. They look at the adoption of Agile methods as providing more “tools in the toolbox” to successfully manage projects. They are absolutely correct.
The greatest thing about the PMI Agile Certification is that it further legitimizes Agile as the most popular, trending and successful project management framework.
Scrum Certification is great, but a sponsorship from the most recognized project management group in the world goes much further to dispel the myths of Agile and provide even more credibility.
GAO and VA Squabble Over Agile Development Project, Procedures.
Agile is a framework of never ending improvement exercises. It simply doesn’t end with attempting Agile (or any method, process, framework or methodology) once and abandoning it without a learning and refinement effort.
Show me something that works better.
Dr. Dobbs Agile Q&A
Nothing Earth shattering here, but still some more good press for one of the best tools in the I.T. arsenal.
At work I’m considered the Agile Evangelist by some and “Agile Boy” by others. Yes, I was once called, “Agile Boy” by a colleague. You know those colleagues right? There the ones that think “Agile is the Devil!”.
They are also the folks who truly believe Agile and Lean methods require no project plan; in fact some believe Agile preaches no planning at all. This is a common misunderstanding that traditionalists hang their hats on to knock Agile down a few pegs in favor of BDUF (Big Design Up Front) projects.
The truth is that Agile demands that a project vision or feasibility develops into a plan and that plan provides enough data for the business (business, not I.T) to make an informed decision towards validating that the vision should have some form of investment placed behind it and we should start an initial iteration or proof-of-concept to further validate our initial plan.
Agile requires more planning than any methodology known to software project management. The message in the Agile Manifesto of “Responding to change over following a plan” is intended to mean, “plan, build tests, analyze, design, code, validate tests, demonstrate working software” REPEAT. They never intended to infer that we sit down and start coding our way in the dark. Conversely, there are Agile purists that believe you should. Both extremes contribute to the great many software projects that fail.
So repeat planning? Yes, over and over again to tighten the vision into demonstrable product over a period of time-boxed iterations or sprints. That’s the agile premise. The PMI (Project Management Institute) embedded a similar construct in the PMBOK several years ago. They call it, “Progressive Elaboration” aka. learning as we go which all projects despite methodology inevitably do regardless of planning accuracy, and “Rolling Wave Planning” which is simply, take what you learned from the last “wave” and plan again, reforecast and tighten up your project timeline.
Sometimes we want to believe something instead of investing a little time to understand it because it feeds our innate desire to avoid change. Change is good, especially in Technology fields; it’s impossible to avoid.
Speaking of change, did you notice in the 4th paragraph of this blog entry how I mentioned, “build tests” before coding? There’s another concept that causes I.T. “faith wars”…more on that some other time.
Agile Community of Practice Members Showcase Their Creativity...
Great PMI Today article featuring creative videos from various teams documenting their discovery and success stories with Agile development practices.
Scrum is not something “I.T. does”
A great one pager by Katie Playfair of CollabNet. Rather than simply touting how Agile and Scrum will positively change your I.T. organization, Katie points out a fundamental flaw in most organizations; the lack of quality communication, collaboration and partnering with the business.
Many organizations think Agile is a silver bullet, but they fail miserably because they don’t address the hidden behavioral debt that they have.
Remember folks, the business leaders must drive I.T. in a servant model and never the other way around. Agile will fail if this one simple prerequisite is missing.
You can follow Katie on Twitter @ http://twitter.com/KatiePlayfair
