“When will it be released?”
In the pantheon of my least favorite software questions, this ranks near the top.
“When it is done.”
This response has to rank near the top of management’s least favorite answers.
“When will it be released?”
In the pantheon of my least favorite software questions, this ranks near the top.
“When it is done.”
This response has to rank near the top of management’s least favorite answers.
No child learned to ride a bike by reading books about it, nor by rigorously documenting all of the steps that will be required in order to do it, planning those steps, then executing those steps. Children learn to ride a bike by experimentation and incremental improvement; they learn by taking minor risks fearlessly until they pay off. Continue reading We Were Born Agile
It takes a considerable amount of bravery to be in the process of moving an organization from waterfall to agile and to ask questions at most agile meetups and conferences. Nowhere in the universe are you more likely to be told that everything you do, everything you think, everything you are is simply wrong. This is one of my biggest pet peeves. Continue reading Moving to Agile: Doing it Right
I haven’t really had the mental energy to write much about our transition to agile for the last month or two because I have been spending so much of that time period putting together and executing trainings. Even with as much enthusiasm as I have for this, it has been a draining several weeks.
The human urge to generate complexity when something seems too simple makes teaching simple things a weird chore. When I walk someone through the thought process behind answering a specific Scrum question, it’s often perceived as too simple—I get wary looks from the audience as if I’m trying to trick them. There is no trick, it’s really that simple. Continue reading Moving to Agile: Training
This post is the third in a series that began here.
It did not take very long for one of our projects to see its first curveball. As our client fell behind on providing information that was necessary for us to progress, we were in danger of running out of work. In our traditional waterfall model, that meant that we were stuck in a common position of having to pull the dev team off the project and delay the progress of the project—pushing the project day-for-day until we have what we need to move forward.
I must admit, it didn’t even occur to me to handle this a different way until someone said in jest, “shouldn’t this magical new process fix this?” Continue reading Moving to Agile: Adjusting to Change
In my previous post I detailed the strategy that I employed in order to attempt to bring a more agile build approach to some of our projects. With a plan in place, I did the most agile thing I could think of…I just started working! Continue reading Moving to Agile: Iteration 0
Over the course of the last 3 months, I have been coaching my team through a transition to scrum development. This hasn’t been simply an exercise in trying something new for the sake of something new; this move has been an attempt to alleviate the problems caused by years of technical debt and unsustainable work practices that have resulted in significant points of pain for our organization. While I would certainly like to get into the why (and that will almost certainly be a topic for a different post), I’d like to focus on some of the details as to how we have chosen to execute the transition. Continue reading Moving to Agile: Strategy
An interesting observation as I work with several teams to migrate a very waterfall process to Scrum: it is ridiculously easy to let the tools and the ceremonies become pro forma exercises rather than thoughtful representations of the spirit of what we’re doing.
I think that the biggest value I add as a coach has been to remind entire teams—regularly—to focus on the spirit of the manifesto rather than following the “rules” for using the tools or ceremonies. The tools do not define our process, the tools are there to facilitate our process. Something to remember.