What does the origin of DevOps teach us?

Recently, I read an interesting story on how the name DevOps came about.

http://blog.newrelic.com/2014/05/16/devops-name/?utm_content=5416574&utm_medium=social&utm_source=linkedin

True enough, as an “afanaciado” of DevOps movement, I didn’t know this story. It even had a reference to the city I work in – Toronto. It is home to one of the two people that caused this name to appear! I am feeling proud, now:-) As I read the story, I was intrigued with Patrick Debrois and Andrew Shafer’s tenacity to pursue what they believe is important for two years in the face of seemingly indifference from the fellow community members. In addition, Patrick’s courage to organize the first #DevOps conference in 2009 on a brand new topic further proved that if you believe in something, follow it up with action, then you will be rewarded. That reward may not be success as in this case, but the experience itself will be reward enough.

That is one of the fundamental pillars of agile. Don’t wait for everything to be ready. Don’t expect all the documentations will be complete. Don’t even think you can spec out all the possible edge cases before building the software. Do execute on what you already know. Get feedback quickly and then build on top of that. You will be rewarded with information/knowledge that otherwise will just be a design/estimate/assumption/risk. As an added bonus, you might just get a working product that’s right for the customer. Isn’t that nice 🙂

Is agile reinventing-the-wheel?

I was training a fairly successful multi-national software company on agile estimation and planning several days ago and a question popped up at the start asking why is agile better than methodologies used in the manufacturing industry? Why is it better than mil-std-498, a standard that promoted iterative development and focuses on quality? Isn’t that what agile claims to do? In essence, why are we reinventing the wheel instead of taking what’s already establish for centuries in the manufacturing world through countless trial & error and proven to be effective? Those are really good questions and ones that I, myself, have asked before, and a lot of people are still asking.

Software is a relatively young industry compared to manufacturing. So, it is logical for software professionals to learn from the experiences and processes in manufacturing. In fact, many software PMLC and SDLC processes were adopted from manufacturing. When it came to agile, it is no different. Methodologies such as Kanban have deep ties to manufacturing world. However, there are many different processes in manufacturing and not all of them apply to software development. Some manufacturing processes focus on streamline the assembly and improve repeatability of producing the same widget over and over again. That doesn’t map well to software development as every application is different from the one before. Software development is an innovation and research process, so software development  is more similar to scientific research or design in the manufacturing world. In addition, agile is more than developing software iteratively. Iterative Waterfall is also iterative development, and the one encouraged by standards like Mil-Std-498, that addresses one important aspect of agile which is doing things in smaller pieces. But it still emphasizes on documentation over working software; contract over collaboration; fights against instead of embraces change; and most importantly, processes and tools over people. So, YES, we should learn from other industries like manufacturing so not to reinvent-the-wheel AND adopt them to software development’s unique characteristics to make the wheel better for our needs.

An Estimate is an Estimate … or is it?

Since the dawn of software projects, we software professional have been struggling with estimates. They are sometimes too large, mostly too small, and rarely bang on. We have tried to employee myriads of processes, controls, templates to it, but it doesn’t seem to get any better. When we say “an estimate is an estimate”, everyone seems to agree, but what gets acted on can be very different. I have observed this same phenomenon in a few different companies.

Development teams are asked to produce an estimate, sometime detailed, once all estimates are entered into a project schedule, it is now a “commitment”. It is frozen and any changes to it must go to a stringent change request process along with many stern stares, among other things. Does that sound familiar to you? Well, it is more common than I thought possible. Some of those companies are also agile shops. How can that be, you ask? The answer is, the management, and by extension the business, needs to plan out expenditure, resource allocation, etc. These all take time. So, companies always budget into the future. Shareholders and the board will make sure the executives are running the company in fiscally responsible manner. That means, when estimate percolates up to certain level, it will be seen as a promise. That is the reality of running a business.

Instead of getting into an argument over how to change the financial models of the world, being an agilist, I think about how we can adapt to it. Software organizations and teams must change their frame of mind when we are asked to provide detailed estimates, or in Scrum terms – set sprint plan, that we ARE making a commitment, rightly or wrongly. What’s important, POs and SMs take notice, is to control the scope and distraction so that the team have the best chance of adhering to it. That is also why, as a team, we should keep an eye on the sprint progress during every standup and an eye on the release/project progress during every retrospective!

The first benefit a decent agile implementation provides to any organization is visibility. The first hill to conquer though, IMHO,  should be predictability.

Patrick Li

 

 

 

Why would a hard core agilist need a PMP certification?

About 6 month ago, I decided to sign up for PMI-PMP certification. At that time, I already have my Certified Scrum Professional certification, using the essay format (which like better than the current multiple choices format, but that’s topic for another discussion), and have coached many scrum team. My move has perplexed a few people, but after I explained my rationale, it all made sense. So, I thought I would share this as the first blog on our site.

I  first thought of getting a PMP designation more than a decade ago when first entering the software development management realm. At that time, it is simply due to the “gold plating” factor. I even studies PMBOK.  However, after encountering and loving Scrum and then various agile methodologies, I have grown to distance myself from PMI’s believe that complete structure, process, and control can lead to successful project completion. I have seen it, over and over again, fail in real life. I had several opportunities in the past decade to get a PMP certification but have always resisted it. Now that I have years of agile experience behind me and having risen from managing teams to look at enterprise-wide agility, I find myself in an interesting position. I often has to debate/discuss the merits of agile against waterfall thinking and find my opponents has raise some really good arguments on governance for larger organizations. In addition, I feel uncomfortable arguing blindly against someone without knowing enough about their believes. Thus, I took action.

I signed up with an online course, www.simplilearn.com, for two weeks. Went through the application process and registered for an exam in three weeks since I started. Without going over the details, I passed it on the first try. That does not mean the tests are easy or that it is ineffective. In fact, the questions are very practical and well thought out. The testing process is Through this short, yet concentrated study of the principles, knowledge area, and practices, I learned to appreciate the thoughts and work that many people have put into body of knowledge. I came out a different man. A more humble man knowing more about things unknown. The most interesting thing I found is that both PMBOK and agile are based on Demings PDCA cycle. Yet, the result of each adaption so different from each other. Maybe it can be attributed to PMBOK contributors came mainly from managerial roles in large organizations and most agile methodologies born from developer’s community. The two communities are approaching the same endeavor from different ends of the pyramid.

Personally, I believe there is value in the knowledge, artifacts, and processes included in PMBOK. In fact, all of them are necessary under certain situation. PMI as an institution is also adapting to the change in the wind and move toward more iterative and agile approaches. In practice, though, the PMLC methodology has been way overused by people to fit most or all situations. What’s worse, is that due to the thoroughness of the methodology, it takes more time to deal with each process and artifact, even more to justify that they are not needed, than it will actually take to develop software. That’s the reason why so many software developers are fed up with PMLC and fell in love with agile. Agile makes logical sense for grass root software development. PM methodology makes sense for business governance. That’s why the “new” breed of methodologies like Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD) have been receiving a lot of attention in the software development community and especially welcomed by large enterprises who are traditionally waterfall shops.

Overall, I am happy with the decision to get PMP. It opened up new perspective for me, especially as senior management and business owner. It also gave me more ammunition and laser guided targets for my agile vs. waterfall discussions 🙂