Category: success
Last week I had a great fun and honour to interview Janusz Gorycki who is a partner and a team manager in an Agile Software Development company - Spartez. Janusz is also the author of the open-source screen capture and painting utility for Windows named Mazio.
In this interview I'm asking Janusz about how they founded their company and how agile movement helped them achieve success. I'm also asking how they see their agility, what problems they have and how they deal with them. Janusz also answers why you can be CMMI-compliant using agile methodologies and recommends steps by which you can start applying Agile practices in your company.
Is this interview about yet another agile company? Not really - Spartez is an extraordinary company composed of ordinary engineers who were not afraid of making their dreams come true. Their determination, team work, a bit of luck and an extreme agile spirit helped them be and work together and become successful. This is a real-life example how cross-functional team, where each member is an expert in some areas, is able to deliver any software to any customer. And how do I know this? I used to be a part of this team at Intel and know this team as well as each member pretty well, however I'm not affiliated with them anymore in any way.
If you are interested in getting to know how they started, what and how they do now, this article is for you. Maybe you will follow their dreams and ideas - I think it's worth.
Bookmark/Search this post with:
I recently had someone pose a question to me that got me thinking about the scalability of agile success. Here was the question: "I'm part of large organization of over 1,000 people. Our small team of 40 has been using agile with a great deal of success. Now our company wants to me to extrapolate the successes we've enjoyed from agile (efficiency, value, profitability) to the rest of the company. Do you think the agile success of 40 people can be extrapolated to over 1,000 people?â€
It's a great question and I don't think there is an easy answer to it. Speaking from my own personal experience, it's been difficult extrapolating the success our small team of five developers had in the past to our larger organization of about 35 people. There are many challenges as you scale agile up. Agile practices depend heavily on collocated teams that are cross-functional in nature. When you start scaling agile up, you need to consider geographic dispersion of much larger project teams that may not be as cross-functional as you'd like them to be. This is just the nature of large organizations.
Bookmark/Search this post with:
I don't believe in repeatable results. I only believe in repeatable success.
Repeatable Results vs. Repeatable Processes
In his recent Agile Newsletter, using the results of the latest Dr. Dobb's survey, Scott Ambler showed his readers that most developers, project managers and IT managers prefer repeatable results over repeatable processes. Not surprisingly, according to his survey results, people in the agile community lean more towards repeatable results than those working in traditional organizations. Most respondents of Scott's survey also reported that their personal preference for repeatable results is bigger than that of their organization. Everything considered, it seems that there is a global shift towards a growing importance of repeatable results vs. repeatable processes.
Bookmark/Search this post with:
When is a software product successful?
We all know industry reports (particularly the infamous CHAOS report of the Standish Group) are always saying that only a small number of software products are “successfulâ€. But what does that mean? People have been struggling to find a proper definition for years and they are still not in agreement. One traditional view has it that a product is successful when it is delivered on time, within budget, and according to specifications. Others say that a product is successful when it matches a customer’s expectations, paying back its investment in the form of business value created, as laid down in a properly defined business case. Another view, often advocated by agile experts, is that a product is successful when the stakeholders are happy, whatever this may signify at the time of delivery. But I think they are all wrong.
Bookmark/Search this post with: