Choosing Smart Development Frameworks
A discussion with a software development coach a week back rang a bell. He said that whenever he heard companies saying they were following agile practices successfully he felt that they were over simplifying the problems that haunt them.
Managers and architects cudgel their brains often to determine what methodology to follow to develop a software - waterfall, scrum, spiral, other iterative models- list is perhaps endless.....please don't lose your mind....
The condition is actually worsened by top down recommendations in organization to follow a specific methodology..." You must use scrum methodology in your projects. The methodology improves chances of success of projects..." and from there on we run blindfolded, obsessed, biased, and sometimes ill-trained....
Since the time I came into the information technology world, I have seen various projects, which followed various agile practices, failing to get a decent rating from customers. What went wrong? Could be they followed it incorrectly and would have been worse following say a waterfall model of development.....It is important to know why you follow what you follow.
On the other hand some of my team members and I, working as solo developers with the customers directly on small individual projects at a very young age (when we were clueless about the nitty-gritty of any methodology), hit the bull's-eye. What went right? Were they less complex....I have often wondered....
Having spent sometime in the industry now and having interacted with preachers of the methodologies, I have developed some perceptions of my own.... might be still evolving....yet let me share my current snapshot of thoughts..
Each organization is different (we all know that!). No matter what methodology you follow, it is the organization itself which offers the greatest challenge. You cannot change people, processes, and systems overnight; culture, I believe, is a function of these elements and also helps to build these...much like the way a feedback loop works. As a project or product manager you need to deal with these - don't you?. Are you inevitably doomed? I will not be that skeptical.... Lot of organizations have built agility, innovation, learning, and more importantly "smartness" into their culture and have successfully rolled out various complex products/projects.
Now the million dollar question: do you want to improve your organization as a leader or do you want to deliver a critical project in an organization bugged with challenges of its own?
As an MBA student, I used to reply back to such questions with the clichéd answer - it depends! (.....and the professor inevitably frowned back).....But it does truly depend on your role and your goals/objectives in the organization (which are by nature short term i.e. valid for the year and which you very carefully draft at the beginning of every year :-) ). Ideally the remediation of the two parts discussed in the above question should go hand in hand. But let's be realistic - the latter is the most common and popular problem. Allow me to drill down on the snapshot further along this axis of thought.
I believe that a couple of core principles or ideas that always help are as follows:
IDEA 0: Understand the big picture of what you need to deliver. You should know where you want to go, at least roughly.
Idea 1: If you get a chance to choose your team , choose well !
Idea 2: Even if you don't get to choose, make sure you spend time understanding the members in your team, stakeholders and processes.
Idea 3: As a team have the "same" understanding around the details of the deliverable.
Idea 4: Understand organizational bottlenecks.
Idea 5: Build a smart delivery framework.
In this article, I will drill down further on ideas 2, 3 and 5.
The result of your actions from 2, 3, and 5 should be such that your team works as if they were a solo developer, working on a small project and closely with the actual customer. Doesn't make sense at all...isn't it? But isn't some of the latest software development methodologies we talk about echo these ideas too?
For example, how do you make your team's deliverable a small project ? - Could be by breaking your deliverable into small chunks or phases, timeboxing etc...rings a bell?
My version of a solo developer works 100% on a single project, works directly with the actual customer, understands requirement, and builds and tests his work continuously - often called test driven development - and gets regular feedback directly from customers too. How to achieve this in a big team? Can they knit together to work just like a solo developer? Are all the team members co-located (oops....did we mention co-located?? Don't we work with global teams)? Are they all 100% allocated to your project? How to get requirement directly from the actual customer? How to prevent leakage in the process of capturing voice of customer, pain points, requirements etc? How to also get feedback directly and regularly from the actual customers?
As a project manager , scrum master, product manager you should understand the level of entropy associated to these questions and minimize the degree of aberration in your delivery mechanism so as to be as close to the bull's-eye as possible.
It is good to train yourself on different methodologies, draw smart practices from various philosophies; but never follow a methodology or any framework blindly or without adequate knowledge of the situation to which those methodologies apply. If required, hire a coach to customize the methodologies and build a smart delivery framework that suits your particular project in the organization. The bottom line is that you should know how to implement them in your case.
To be continued.....
