I found this article on the Defense.gov website and it seems they made a decision to go Agile with how they procure and deploy IT:
So, based on recommendations contained in the 2009 Defense Science Board Report, the department is working to speed up the route to acquiring new systems by increasing collaboration and improving processes, McFarland said.
“To do this, one must start with the defined requirement or capability,” she added.
In the past, once an IT requirement or capability was defined, organizations were able to acquire only that technology which precisely met the predefined parameters.
The introduction of the “IT box” concept is a significant change to the IT acquisition process, McFarland said. The IT box gives organizations the ability to acquire technology that improves on already-approved technology, as long as the changes don’t exceed certain parameters.
In addition to the IT box, the department has introduced interim guidance to adopt “modular, open system methodology, with heavy emphasis on design for change,” which will help DOD adapt to the changing IT environment, the assistant secretary said.
“The policy addresses the realization that IT capabilities may evolve, so desired capabilities can be traded off against cost and initial operational capability to deliver the best product to the field in a timely manner,” she said.
I still find the statement confusing. On the one hand, they are saying they need IT requirements to meet "predefine paramaters", but will also need to heavily emphasize "design for change".
Maybe the goverment works in a different reality, but that's not how Agile typically works. If I'm wrong, please let me know!
It seems lately that I'm finding quite a few articles on the web where people are moving away from Scrum to Kanban. As this post from the blog "Journey of Continuous Improvement" indicates:
Some people will argue that we weren’t doing Scrum right so no wonder we had problems. But this is the crux of my problem with it – so much effort goes to doing scrum instead of channelling that focus to building better software, faster. For my team, using Kanban to liberate us from a prescribed process and visualising the way we worked allowed us to have this focus. I think there is a misconception that Kanban is a process and directly comparable to scrum. I don’t see it like that. I see Kanban as a set of practices which helps teams define their own way to work with absolute freedom. It wraps around your way of working and helps you refine it.
The section about liberating from a "prescribed process" was interesting to me as many think Scrum is about being flexible, but in reality if you're doing it "right" you have to come up with good story point estimates and plan your Sprints to ensure you deliver working software at the end of a Sprint. Estimating is notoriously hard and even more so if you're doing cutting edge software.
In this post from "Blue Sky on Mars", it outlines a similar sentiment:
With Scrum, this sort of planning is built-in to the process. You estimate all of the stories in question, add them up and divide by the velocity to find out how many sprints it’ll take. Or, compute how many sprints you have and then you can choose which stories fit best into the time you have.
In the Kanban process, you can get the same kinds of useful estimates by computing “cycle time” and “throughput”. Cycle time is the average time it takes for similar-sized stories to work their way across the board. Throughput is how many similar-sized stories are done over a given period of time. Using this combination of data, you can do the same sorts of planning you can do in Scrum. As a bonus, cycle time and throughput are easy to compute, and should be easy to adjust when exceptional conditions arise.
Though completely anecdotal, I'm not surprised by this trend. It seems the typical transition is from Scrum, to Scrumban to finally, just Kanban. Could it be that the pace has gotten so fast that even Scrum is starting to feel like a bottleneck? Will Kanban be the new Scrum going forward?
As I’ve matured in my career as a project-based professional (I’m really not a project manager anymore), I sometimes like to go back to industries I was previously engaged in and one that I regularly like to stay abreast of is information technology and software development in particular. As I mentioned in a previous post on adopting the Liskov Substitution Principle (LSP) to designing requirements so that changes to them and transparent to the end customer, another I find useful is the idea of refactoring.
As Wikipedia states:
Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility.
This is basically Lean and another form of 5S. I like the idea of improving “nonfunctional attributes” as keeping things clean and continuously improving is not always about improving the functional stuff, but also by keeping things clean and organized on a continuous basis, this leaves a foundation for efficiency and effectiveness.
In any event, a rigorous process of eliminating waste, clutter, duplications and redundancies all the while maintaining simplicity and elegance of solutions is a prescription for success in projects and life in general.
I happened to run into this discussion thread and the most interesting discussion was on the topic of just “enough up-front thinking” which this poster David Chelimsky, responds:
In regards to enough up-front thinking, there are a series of scopes to which it applies. When you’re in a release planning meeting you want to do enough up-front thinking to be able to start working on the release with confidence. This will likely include considerations like business strategy, marketplace, etc.
In an iteration planning meeting, the scope is narrower. The goal is still to do enough up-front thinking to start working on the iteration with confidence, but the considerations tend to more about the functional details of specific features that we’ve already selected in the release planning meeting. Perhaps you don’t do separate iteration and release planning meetings, and that’s fine, as long as you recognize that even in the context of a single meeting, the concerns for release planning are wider than the concerns of iteration planning.
Within an iteration the scope is narrower yet. You still want to do enough up front thinking, and perhaps you’ve recognized some design challenges that are presented by the features slated for the current iteration. In that case you call a design meeting with your peers. The goal here is stay within the scope of what you’re doing this iteration.
Then, when you get down to the minute to minute practice of doing TDD, the scope is even narrower. The focus is on objects and how they respond to events in given contexts.
At each level, we’re informed by what we know from the wider scopes, and we can’t help but consider the things we know. We’re human, after all. The trick is to avoid the temptation of considering the things we don’t know or are not relevant to the task at hand.
I like this idea as it outlines a form of “mental agility” that forms the basis of acting on information that you obtain “just in time” to be able to get work done. But as the post outlines, it is still driven by the overall goals of the project and the key is to eliminate the fluff while focusing on the meat. As I’ve critiques in the last couple posts, Agile is too focused on processes and not enough on the thinking and most importantly, the behaviors you need to adopt in order to have true agility.
Look forward to thinking “just enough” about this and posting more about it!
(NOTE: The post below is not really my personal view, more of a sentiment I'm seeing amongst those practicing Scrum, though I agree much with it.)
I really loved the idea of Scrum, really I did! But I’m starting to realize that in reality, what was supposed to release me from the shackles of the tyranny of my Gantt chart cum waterfall ways is the fact that I’m now feeling the very same burden and overhead for which I wished to escape!
The fact is that Scrum ass-u-me’s that we are good at estimating. In fact very good, because only then could you finish a working deliverable at the end of each Sprint. The problem was that we’re not, yet the irony is that by breaking things down into Sprint iterations that were badly estimated, we ended up jerry rigging the estimation for the next Sprint which cause Sprint after Sprint to miss their deliverables. Rather than get frustrated over a prolonged period of time after a traditional planning process, we would get bursts of frustrations that started making us exhausted.
On exhaustion, while it initially seemed a great idea to have daily stand-up meetings, Sprint planning meetings and all that good stuff, like anything else people show up and are enthusiastic at first, but then as time moves on and the bottlenecks start to occur as described above, you as ScrumMaster will become quite prickly and everyone working around you demoralized or bored.
And for all you “Certified Scrum Coaches”, don’t tell me that “we’re just doing it wrong” as that’s starting to sound trite. I harbor no grudge against the Scrum framework, but like all good things it must come to an end and someone (maybe me!) will come up with a new twist to an old trick and get us all moving and excited again (Kanban anyone?).
Scrum, it's not you, it's me and hope we can still be friends.