Attila Buturla

Posts

Achieving Flow: Part 1

One of the central tenets of agile software development is the ability to quickly respond to change. Instead of planning for months or even years at a time, as was common before agile, many software teams plan in short 2-3 weeks iterations. While that's certainly an improvement, to a much lesser extent there are even more nimble teams that deliver daily. There are many things that impact a teams ability to deliver quickly. Technical debt, unclear business needs, and constant interruptions are a common few. However, by and far the largest one of them all is not widely recognized. It's all of the waste we have baked into our processes. Let's examine a typical scrum sprint. The product owner comes up with requirements in the form of user stories. During the sprint kickoff the requirements are reviewed with the team. While many questions are answered during this meeting, ultimately more questions will come up afterwards. If the product owner is not immediately available to

Fear, Control, Safety, and Trust

After having been in the software industry for over 17 years now, I've seen many approaches to running software projects. I've worked in companies that had just under 20 people, to large corporations that employed several thousand. The projects have included products that are used by millions of people, to internal software that was highly regulated. Despite all of that variation, I can pretty much break down all of the projects in two categories; projects that are run via command and control and projects that are run with collaboration and trust. One might assume that the projects run via control are always at large corporations, or from more regulated industries. But in my experience that isn't necessarily the case. The biggest company that I worked for was also perhaps one of the most progressive in terms of practices, while some of the smaller companies were just the opposite. Perhaps not coincidentally the largest and most progressive company was also the most succes

The Product Owner

According to the Scrum alliance the Product Owner is "a single person must have final authority representing the customer's interest ...". They are often described as a product visionary, and also as someone that has a lot of influence within an organization. That is to say that they are the final arbiter for the product. In short this individual has a tremendous responsibility and in many ways are responsible for the success (or failure) of the product. Unfortunately, in my experience, this is not how the the role is implemented. I believe a lot of this has to do with how software projects were run in the past. I've seen several common variations of how they they are often fulfilled. The first being the PO believes that they need to perform more as a Project Manager. They focus more on control, and trying to manage the team. This often comes from people with experience from pre-agile days that either don't fully understanding how the role is meant to implemente

The Retrospective From Hell

Over the last 17 years of my career I'd like to think that I've learned a lot. I've learned from positive role models, from experience of what works well, by studying my craft, and from my own trials and tribulations. However, I believe the lessons that I have learned that had the biggest impact is learning from failures. One such failure occurred at a previous employer. By telling the story of a past failure, we can reflect and see what can be learned from it. No names will be mentioned, no embellishment or poetic license will be will used. As a matter of fact, I will make every attempt to be objective and accurate as possible. The truth of the matter the story doesn't need it; it speaks for itself. Some time ago I worked for a company that, among other things, had a software product. There was a small team of software developers, and someone that acted as the manager of the team. I was brought on board, as a software engineer, to help with the software product as

Our Experience With Mob Programming

I was first made aware of Mob Programming well over a year ago. While I've always felt that you can do great work in collaborative environments, I have to admit that at first I was somewhat skeptical of the idea. How could having the entire team work on one thing at a time be as productive as everyone working in parallel? Having said that I considered myself open minded and am always willing to give something a chance. As mentioned previously, I've had great experiences working collaboratively in teams. In the past I worked on a large team making complex software, and our best work was produced after designing as a group with white boarding sessions and intensive debates about best approaches. I had also worked for a Credit Union, and worked hand in hand with the business to help come up with ideas on how to best utilize technology to solve their business challenges. Only by collaborating as partners were were able to come up with practical solutions that properly addressed

#NoEstimates Year in Review

The hashtag #NoEstimates was originated by Woody Zuill for "exploring alternatives to estimates [of time, effort, cost] for making decisions in software development." What began as a conversation between a few people ( Woody , Neil Killick , and Vasco Duarte ) grew into a much larger discussion. As the year 2015 is now over, let's take a look back at what we learned from the discussion. A lot of different people have participated, each bringing their own unique views and experiences. There is no single "#NoEstimates view"; what one person says doesn't represent the rest of the group. Some argue that estimates should be used more sparingly, others never at all, and yet others that suggest that only under certain circumstances . Despite the differences, there seems to be consensus on the following key points: Software project often fail. Perhaps the use (or misuse) of estimates play a role in this. Estimates are often turned into commitments. This mech