Agility and more: better & faster business solutions with software - part-1
Comments
Software development is a creative process, where we create software to deliver solutions to business problems (most of the time), and/or to add value to it. Although the holy duty of a software developer is to deliver solutions to business problems, and not always necessarily developing software. But when we have decided to build a software, we work as teams (most of the times), and the business problem is the central focus of the process. But, the overall quality of the developed software also depends on how we are developing the software - from the requirement capturing to coding, testing, and implementation. This highlights the need for a process at all stages of software development.
These series of posts highlights my understanding and experience on how the Agile processes can be effectively used to improve the overall quality of the software solutions with reasonable time leads and better estimates. Why and how agile processes needs to be adapted? For Software Engineering teams, there is even more than just being lean/agile, that needs to be into the process.
This is of course not a comprehensive discussion on any of the process tools/frameworks discussed here. Although I discuss about Scrum, XP and Kanban to certain extent, what I tell here is the basics, a skeleton that every team/organization can give thoughts to, and then adapt them to their needs. You may add whatever more is needed to meet some standards, but just don't overdo it that you have problem remembering your own processes - keep it as lean as possible. There are several literature that talks about these specific techniques. I will not talk about all the aspects of software development too! Here I will talk in general, about faster development cycle and developer productivity while achieving quality and timely software releases with less team burnouts and overtimes.
Although, I have practiced focused agile processes for almost 2 years now, I do not consider it as too long to be compared to the seasoned agile experts. Nor do I have done any agile/lean consulting for organizations. But I do talk to peers, friends, friends of friends and seek their experiences and suggestions, share mine with them, and advice them. I read a lot, or get to watch conference videos and slides on agile processes and tools, on developer productivity, apart from the efforts on improving my technical skills. I still look forward to attending user-groups and conferences to discuss out these things. This is why that I feel that I need to share my experiences and learning with others, especially for those who have not yet started on a good agile practice, or are trying to find experiences of others to improve their own processes. After-all, process improvement is more to do with experience - learning from our own and from others, sharing our own and getting valuable feedback, and further improving.
With this statement, let us have a quick description of a good software:
With this small description of a good software, we can now focus on making good software, where we need people and processes.
Since the overall quality of the software developed also depends on how we are developing the software, the need for a organized process to produce the software becomes important. Process models such as CMMi evolved over years with this focus - "provide organizations with the essential elements of effective processes that ultimately improve their performance". Over the years people found iterative and Agile methods to be more effective in delivering better output. And in the recent times, there has been a considerable shift to adopting leaner agile models such as Scrum and Kanban over heavier and prescriptive process models such as RUP. Prescriptive means that there are more rules to follow, and adaptive ones have lesser rules to follow. Agile methods are lightweight since they are less prescriptive than the traditional methods of software process. Even within agile, the leaner and less prescriptive models are becoming more popular, naturally, because they are more adaptive to one's organizational needs and seem to be more effective and easy to learn and practice than the prescriptive ones.
Even with the need for processes to govern the software development, there are more reasons to go for agile process.
Of course, seasoned agile practitioners can find even more points to be added to the above. But this is what was very obvious to me.
Note: Software is also developed for fun, some write it to learn programming (we all have did that), some times it is written for personal use (eg,. automating some mundane task). But most of the time, its written for business needs - let it be a game software, and ERP, the OS itself, or the search engine software - most of them eventually turn as a business or a business solution. In this post I am talking mostly about the software that deals with business and hence the software shops find time and money to be spent to develop these software. So whenever I talk of software, I mean it to be the software developed in these software shops, unless otherwise indicated.
These series of posts highlights my understanding and experience on how the Agile processes can be effectively used to improve the overall quality of the software solutions with reasonable time leads and better estimates. Why and how agile processes needs to be adapted? For Software Engineering teams, there is even more than just being lean/agile, that needs to be into the process.
(Image courtesy: Coffish's web album)
This is of course not a comprehensive discussion on any of the process tools/frameworks discussed here. Although I discuss about Scrum, XP and Kanban to certain extent, what I tell here is the basics, a skeleton that every team/organization can give thoughts to, and then adapt them to their needs. You may add whatever more is needed to meet some standards, but just don't overdo it that you have problem remembering your own processes - keep it as lean as possible. There are several literature that talks about these specific techniques. I will not talk about all the aspects of software development too! Here I will talk in general, about faster development cycle and developer productivity while achieving quality and timely software releases with less team burnouts and overtimes.
Why this talk?
I am into the software development profession for over 4 years now and about 7 years overall into the world of software. I have developed software the ugly way, the good, way and still an ever improving way that gets better each passing day. I was very fortunate to have a wide variety of experience in such a short span. I've worked as a junior programmer to leading teams. I have been a Scrum Master for nearly 2 years. I continuously look out to improve myself and the environment in which I work. I try to implement my learning whenever possible, and its a continuous process where the learning and improvement never stops.Although, I have practiced focused agile processes for almost 2 years now, I do not consider it as too long to be compared to the seasoned agile experts. Nor do I have done any agile/lean consulting for organizations. But I do talk to peers, friends, friends of friends and seek their experiences and suggestions, share mine with them, and advice them. I read a lot, or get to watch conference videos and slides on agile processes and tools, on developer productivity, apart from the efforts on improving my technical skills. I still look forward to attending user-groups and conferences to discuss out these things. This is why that I feel that I need to share my experiences and learning with others, especially for those who have not yet started on a good agile practice, or are trying to find experiences of others to improve their own processes. After-all, process improvement is more to do with experience - learning from our own and from others, sharing our own and getting valuable feedback, and further improving.
What is a good software?
The Economist magazine (Nov 27, 2004 p. 71) cites the Standish Group's estimates that"...30% of all software projects are canceled, nearly half come in over budget, 60% are considered failures by the organizations that initiated them, and 9 out of 10 come in late."
With this statement, let us have a quick description of a good software:
- Solves the business problem at hand
- Gives and adds value to the business and hence the customers
- Evolves with customer needs (as fast as the business itself): Maintainable
- Free of bugs :)
- Could be built and deployed with lesser cost
- Available to use on time
With this small description of a good software, we can now focus on making good software, where we need people and processes.
Need for agile
Putting it fast, being agile helps foster better output for software shops. However agile is a too general term to be practiced or explained as such, although the general aims and principles of agile is clearly stated at the agile manifesto. Hence, we will need to follow the process tools that have been designed with the agile principles, such as the Scrum, Kanban and XP.The Agile Hype
Often people get confused on "what is agile"? The Agile Manifesto is the defining document of "agile." It lists 4 fundamental values and 12 guiding principles. That is the full definition of "agile." Based on those values and principles, we are expected to derive processes and practices that are consistent with the agile approach. However, often the term Agile has been over-hyped, that the people often do not recognize the true meaning of agile. The hype has infused software vendors to come up with tools to support agile, that has often increased this chaos, where people believe that they need those tools to go agile. Also, agile practitioners, often refer to a certain school of practice as Agile. With various schools of agile practice, new comers often get confused about Agile.
Dave Nicolette explains why is it so hard to find a clear definition of "agile"?.
Since the overall quality of the software developed also depends on how we are developing the software, the need for a organized process to produce the software becomes important. Process models such as CMMi evolved over years with this focus - "provide organizations with the essential elements of effective processes that ultimately improve their performance". Over the years people found iterative and Agile methods to be more effective in delivering better output. And in the recent times, there has been a considerable shift to adopting leaner agile models such as Scrum and Kanban over heavier and prescriptive process models such as RUP. Prescriptive means that there are more rules to follow, and adaptive ones have lesser rules to follow. Agile methods are lightweight since they are less prescriptive than the traditional methods of software process. Even within agile, the leaner and less prescriptive models are becoming more popular, naturally, because they are more adaptive to one's organizational needs and seem to be more effective and easy to learn and practice than the prescriptive ones.
Process models: both extremes of scale does not seem to work well.
(Image reproduced from InfoQ minibook)
(Image reproduced from InfoQ minibook)
Even with the need for processes to govern the software development, there are more reasons to go for agile process.
- Your customers have continually evolving requirements and changing requirements
- Your customers are not very sure about their requirements, and they need your help to identify those requirements
- Your team needs to respond quickly to change requests, and deliver projects
- You need have a major rework of the project just delivered, because of requirement mis-understanding with customer.
- You have teams working overtime continually and at other times sit idle waiting for the other team/person to complete
- You have chaos in team due to lack of communication (many times you never feel that your teams have this problem!)
- Managers are over burdened, and often need to go in to resolving issues between teams that work on same project
- Your estimates prove wrong and your projects go over-budget and/or take longer to complete.
Of course, seasoned agile practitioners can find even more points to be added to the above. But this is what was very obvious to me.
More to come...
In the following posts in this series, I will explain about practicing agile in real life, and why adapting the agile prescriptions is important. I will also explain about practices even beyond the direct agile prescriptions, that can help organizations to build faster and quality software.Update...
The older comments are all gone! I recently migrated my blog from blogger, but the Google+ comments are too stubborn and crappy to be migrated. I am now starting all over again, and decided to instead use a new commenting system from Disqus.
blog comments powered by Disqus
