cf.Objective() Session-- Waterfall to Agile: Improve your Project Workflow Without Drowning
Posted by
Brad Wood
May 08, 2013 07:11:00 UTC
cf.Objective() is almost upon us and I'm super excited as this will be my first year as an attendee and a speaker. I wanted to give a brief teaser for my session, "Waterfall to Agile: Improve your Project Workflow Without Drowning" which is currently scheduled to occur at 1:45 on Saturday the 18th. I am the most excited about this topic and here's some reasons why.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
It is on these tenants that the Agile pathways of Scrum, Kanban, and Extreme Programming, etc. are built. They are about focusing on what the customer needs/wants, delivering early, getting regular feedback, and constantly improving the process.
At my last job, our Agile adoption wasn't perfect, and it wasn't always well-received outside of our department, but it made a marked improvement on our internal communication, prioritization, and how we set expectations for software delivery. With our regular review meetings and retrospectives it was always a work in progress with constant buy in from the team. It was our process and we worked to improve it just as it worked to improve our product and ourselves.
History
Even though I just started working for myself last month, I spent the previous 10 years in corporate America working for "The Man" on teams of about 10 developers. Lots of projects came and went, some being more successful than others. Being a developer can be frustrating sometimes. Whether it's being debilitated by meetings, changing requirements, or just crazy expectations by your employer.Problems
A couple years ago, my company made the plunge into Agile. Some of us knew a good deal about it, others of us knew nothing. With a series of Agile webinars under out belt, we ambled off in the direction of Scrum utopia. One of the statistics that really struck me from our training was that 45% of code that is written is NEVER USED. Thrown away, and trashed. Not what the customer had in mind, unwanted features, or unnecessary complexity "for the future". There are a lot of reasons why developers write code that isn't wanted and many of them relate to communication, priorities, and ill-fitting processes. One of the first reactions when a project does not go well is to define more processes and checks. Sometimes though, that can just push an organization farther into the bad behaviors of a waterfall process.Silver Bullet
Just kidding-- there is no silver bullet.Making Improvements
There is always room for improvement though, and the main tenants of Agile are a good place to start. The Agile Manifesto plainly states:We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
It is on these tenants that the Agile pathways of Scrum, Kanban, and Extreme Programming, etc. are built. They are about focusing on what the customer needs/wants, delivering early, getting regular feedback, and constantly improving the process.
At my last job, our Agile adoption wasn't perfect, and it wasn't always well-received outside of our department, but it made a marked improvement on our internal communication, prioritization, and how we set expectations for software delivery. With our regular review meetings and retrospectives it was always a work in progress with constant buy in from the team. It was our process and we worked to improve it just as it worked to improve our product and ourselves.
Tell Me More
This is just the beginning. I'll be talking about the inner workings of Agile-- specifically Scrum and Kanban at my session on Saturday. If you're at cf.Obective() this year, I'd love to see you at my session. I'll post the slide deck after the session. If you're missing the conference this year, I'd still love to talk about Agile to your user group some time.
Tags: cf.Objective()