Agile Montage

Signatures of Distrust in Agile Teams

2012-01-19T06:00:00.001-08:00

Trust is one of the key attributes of any successful agile team. Its lack hurts the velocity and increases the stress level in members. This, in most cases, is unsustainable. I would recommend a thesis titled, 'The role of trust in strategic alliances' (Michaela Weinhofer, June 2007. Baltic Business School, University of Kalmar, Sweden). Two simple definitions of trust from the references in the thesis are:

Combination of credibility, predictability, and straightforwardness, and
Decision to rely on another party under the condition of risk.

The cooperative relationship required to achieve a common goal can hardly ever be built with distrust. The reason I say "hardly" is because experts (referenced in the above thesis) think cooperation and trust are independent entities. The relationship may be cooperative but not productive. I would also highly recommend The SPEED of Trust: The one Thing That Changes Everything by Stephen M. R. Covey.

For an agile team, how will you know that you are in a distrustful relationship? Here are some symptoms:

Perpetually prioritizing new functionality over defect fixes.
Continuous scrutiny of velocity, deep interest in individual developer velocity, pressure to sign-up more points than velocity.
Questioning story estimates beyond a reasonable limit.
Avoiding story splits fearing 2 plus 2 won't add up to 4.
Comparing actual effort to estimated effort.
Key leadership (technical and non-technical) entrusted to non-team members
Attempt to pile-on stories mid iteration in the interest of getting more done.

There are many reasons contributing to above situations. It could be lack of awareness or lack of experience with Agile. But don't discount the possibility of distrust as a driver.

[ Image taken from: http://www.rockwerxclimbing.com/3292.xml ]

Guilty of a Process Diagram - Don't be, just be Smart

2012-01-19T06:00:00.000-08:00

"Let's not get this process too heavy", "We'd prefer lightweight over the traditional heavy". Everybody has got process diagrams, even in the Agile sphere. You don't believe me? Ask any Agile manager and you'll get at least two; a defect triage process diagram and an iteration lifecycle diagram.

Replacement for Common Sense
You probably have a process diagram that you loathe and scoff at. Usually processes are proposed and adopted to replace common sense and then, even worse, compliance is monitored. If you have to have them, processes should be guidelines to remind folks of the steps and sequences in case there are doubts. The idea should be to provide support to those who need guidance; beginners or occasional troubleshooters.

Analogous to an Elevator Pitch
Based on observation (haven't come across a research on it), I have concluded that most people prefer simple processes but fall in the trap of creating complicated ones. That calls for a couple of rules of thumb:

Start so simple that you void the decision box. If you are using decision boxes, chances are you are in the realm of questioning people's common sense.
Expand a process area only when team members are missing the boat. If team members repeatedly fail to execute a certain step, question its need first.

In gist, a process diagram should be a very high level happy day path free of clutter designed to handle unhappy day scenarios. An analogy for a good process diagram is to an effective elevator pitch; crisp, clear, and simple.

It is important to understand the 'why', specially if you have to innovate. And if the 'why' is clear, there's no reason you'd ever stand complicated process diagrams.

[ Image taken from: http://www.basement.org/2005/12/weird_naked_white_collar_guys.html ]

A Case for Enhancing the Agile Triangle

2012-01-17T06:00:00.001-08:00

The Iron Triangle (Project Management Triangle) is an antithesis of Agile mindset. Jim Highsmith recognized it and proposed the Agile Triangle. It seems that the value vertex, releasable product, is still narrow in its focus. It is talking just about product/service value. It is restrictive to only customers and shareholders. How about Employee/Team Value? Or, even intermediary value focused on enhancing the core environment and sharpening the saws. For better software, we ought to think of empowerment, leadership and mentorship.

I want to make a slight modification to Jim’s triangle and add Intermediary/Internal value to the Value vertex. We just can’t ignore that anymore. That’s how continuous improvement happens. That’s when you take time out and act on retrospective tasks. That’s when functional product ownership balances itself out with technical product ownership.

An Agile approach to product delivery encompasses enabling the people and infrastructure. We just can't think at the project level anymore. We ought to start focusing on the whole organization. It is untenable to continue delivering external value without investing in internal value. The risk of not doing so is to put continuous improvement on the back burner.

A new normal, but a bad normal

2012-01-12T16:44:00.000-08:00

In the last few years, I have been focusing on Agile Pathologies. My thesis is that as individuals we exhibit certain patterns of thinking, reacting, and politicking that usually impede Agile adoption. At times it is outright contrary to what Agility is all about. We can blame the tools, spaghetti code base, team distribution or whatever else you have, but Agile adoption is a people challenge.

A few in the industry discounted my views. Some examples:

"People behave in fairly predictable ways."
"That's within the realm of normal human response."
"80% of projects fail because of lack of attention upfront."

We are considered knowledge workers and supposedly can intelligently deep-dive to fix our problems. Under this misconception, we have built a culture of band-aiding the broken bones when it comes to people issues. This is the new normal, but it's a bad normal.

With Agile manifesto, the software development community for the first time officially declared people to be more valuable. If we really believe that, we have to try hard to identify a pattern in people problems, and address their root causes. Or else the debate will not cease, “Is Agile the best way to write software, or is it the way best people choose to write software?”

Just as any good constitution or a body of law isn't of much consequence without understanding the basic principles and right execution, so is Agile. By execution, here, I mean responses to emerging problems and situations. Good Agile environments need relentless focus on improving people issues. More importantly, they require that we are hawk-eyed in spotting pathologies.

[Image taken from: http://www.zimbio.com/pictures/UXs56SKql2q/Italian+Team+Training+Session/3EfoOAs1Rqt/Marcello+Lippi ]

Speaking at Agile Development Practices East

2011-10-04T16:20:00.000-07:00

On Thu, Nov 10, I will be in Orlando to share my views on some recurring anti-patterns I have encountered during Agile adoptions. If you are an Agile manager or sponsor, or want to be one, and have ever wondered if Agile is a fit for you or your organization, this session is meant for you. I will share some war stories and my secret sauce of success on ThoughtWorks' engagements.

I will delve into these pathologies at four levels; individual, team, management, and organization. We'll have a look at the 'Agile Iceberg' and try to define what an Agile Transformation means after evaluating notions such as 'Preconventional' and 'Postconventional' agility.

As a speaker I get to share with you $200 discount. Just use the discount code, SPAS, to register. With an additional early bird discount of $200, this should save you $400 for conference registration.

Here are some links to the program:

http://www.sqe.com/BetterSoftwareEast/file/BSCE%202011%20Broch_FINAL.pdf

http://www.sqe.com/AgileDevPracticesEast/file/ADPE%202011%20Broch_FINAL.pdf

Agile Frontier: Where's Agile not Working Yet

2010-11-08T21:00:00.000-08:00

"What kind of projects are suitable for Agile?"
"We've got to be careful in choosing projects that we want to be Agile."

At the onset I must make it clear that a big component of Agile is continuous improvement. That said, generally speaking improvement can usually be made most of the times; especially if Agile is not yet an established approach within an organization. The reason is simple, while most people focus on the structure of Agile and appreciate its aesthetics and lightweight nature, good Agilists focus more on its soffits; rigor, discipline, Socratic approach to problem solving, etc.

Relatively small and/or web-based projects have been experimenting with Agile for quite a while. The knowledge base in the Agile community on what works and what doesn't with such projects is rich. The landscape turns dismal on some other fronts, primarily due to lack of experimentation. In some instances a whole section of software community has been insulated from Agile. A prominent case study is Siebel (more on that in a later post). The idea in this post is to discuss some of the environments that are still a frontier for Agile. Without further adieu here's where Agile is struggling:

Big Opaque Software Frameworks: Ownership, access, and control over the code being written is vital for software teams. If developers can't modify a code base to suit their needs and hook other 3rd party tools into it, they can't really derive a fundamentally sound and quality product out of it. Basic practices that contribute to stability and quality of software like Unit Testing are hampered due to inability to touch this code base and, again, lead to a poor quality product. Lack of unit testing in turn, usually, lowers the confidence level of developers who want to refactor the code. Thus they avoid it , which leads to inefficient designs.

Shared and Aggregated Environments: Rolling software changes into environments and databases that affect organization wide operations are not too well suited for Agile development on their guts. Some changes are impossible to make and other very expensive. An example would be a common environment shared between inventory management, inventory ordering, and inventory finance and accounting systems. A spaghetti like this with myriad of inbuilt interdependencies usually warrants heavy frontloaded analysis. Regulatory oversight only makes the matter worse. e.g. a change made to an Oracle module once made might be difficult to roll back due to financial and regulatory restrictions. Often the Big Opaque Software Frameworks (above) almost mandate a heavy analysis and design phase. Big ERP and CRM applications fall into this category.

Software Hardware Boundary: This is the most exciting and promising challenge that Agile will have for a few years to come. Traditional heavy equipment and machinery manufacturers that utilize large scale control systems are getting comfortable with Agile in their software shops. Some of them are trying to take Agile out to their manufacturing plants and experimenting with how to make the mechanical design teams work with software design teams. Agile has not yet addressed the complementarity in software and hardware design. How can hardware design keep up with the software as it is evolving and vice versa? They inherently seem to have not just different characteristics of work cycles but also skill sets and personality traits in their ranks. Agile approach to software is largely unknown in the manufacturing world. It's a challenge of lag, lack of experience; hence the frontier.

Untamed Team Distribution: Lack of interaction between software development teams and business stakeholders adversely impacts the feedback cycle and affects quality of the product. Development velocity takes a hit and ultimately feedback cycles lengthen to a point where rework increases and impacts velocity. Agile leaders in the industry have figured out approaches to make Agile work in distributed environments but only when the teams distributions are purposefully designed, i.e. they have the luxury to choose the people on the teams and their physical location or have a say on the rotation schedule of people between locations and teams. The persuasion to form teams with individuals that are dispersed between multiple locations across different timezones and are "staffed" on projects because they happen to be available might backfire and lead to woefully suboptimal value. Designing for Agility is a resource management challenge, and therefore a frontier.

Systematizing Agile: A natural propensity once Agile has delivered a few success stories is to systematize it in an organization. This urge for "systematization" is detrimental to Agile's success. Agile is not Coca Cola; each implementation is different and should be different to suite the needs of an individual project's needs. Systematization and templatization curbs the "inspect and adapt" nature of Agile. A challenge, therefore, emerges. How can Agile be institutionalized such that the necessary functions within corporate like budgeting and accounting can still run efficiently, smoothly, and cost effectively? How can financial planners ensure optimal use of available resources and timing of investments? This is not to say that in the traditional world financial planners are blessed to have projects executed as they had planned. Projects are extended, teams underdeliver, and expenses are all over the place. Not to mention that the OpEx CapEx ratios are much different than initially planned. The challenge therefore is to build accounting communication and data-churning tools that can react to the realities of projects on the ground. Agile, I think, catapults this necessity to forefront. However, Agilists haven't yet built the tools or reporting mechanism, to the best of my knowledge, that addresses these specific needs of financial planners.

Agile Scalability: 60-70% capitalization rates in software development industry are not unheard of. They are rare, though. On an average this rate is around 20%. Since software capitalization rate is far less (or even none due to short spans between technical feasibility and actual development) in Agile it essentially becomes unattractive for corporation to even think of agile transformation across the portfolio without getting creative and aggressive about it. That's a risk, I don't think anybody is willing to take. The outdated (in context of Agile software development) FASB edicts pose a huge barrier to scaling Agility in large software development environments.

Talent: With the growing adoption of Agile comes a sad realization. It's still the people that make the difference, as they always have. A common misunderstanding in the community is that it's the lightweight process and use of innovative tools and techniques (e.g. TDD) that make Agile successful. If Agile is as much about the people as it is about tools, then we have a significant problem at hand. Scaling Agile within an organization suddenly seems to be a herculean task. Who are these people that "get" Agile and where can we find them?

Now some would argue that regulation intensive environments are not conducive for Agile. True. But that's all there is to it, it's not conducive but Agile is works in many such cases.

This list is a work in progress. As I encounter other challenges you'll definitely see them reflected here. Change is an eternal process and I hope that the next time someone is thinking of making a change in any of these frontier environments (s)he considers Agile as a creative process that teaches us to confront novelty and improvise as opposed to a new "process" or a "methodology" that comes with its own peculiarities of Do's and Don'ts.

Image take from: http://antarcticsun.usap.gov/aroundTheContinent/images/pole_plane.jpg

Agile Release Planning

2010-10-28T06:02:00.000-07:00

"Almost every project has it; there's nothing new about Agile Release Planning." Not quite! What's different about Agile Release Planning, like many other good Agile practice is that it is lightweight, inclusive, and a living plan that is well socialized. Every release plan is different. The anathema of the traditional release plans, though, are their elitist origins, seclusionary existence, and staleness. The realities of project kick in and then an eerily familiar yet enigmatic (to me) behavioral (anti)patterns start to fortify; the unrealistic to begin with plans morph into contracts between IT and Business and nothing ever changes - budget is set, schedule does not move, and scope of course only increases.

Someone once said to me, "You Agilists are lucky". I think, he meant to say that Agilists are pragmatic and call out the fashionable insanity of planning. The notion that neither scope nor schedule and budget move is untenable. Release Plans are and should be evolutionary by nature. This evolution stems from other Agile practices like prioritization and iterative design practices.

The slide deck below is an aide I use to convey the above message.

Release planning

View more presentations from udairaj.

Agile User Stories

2010-10-27T21:00:00.000-07:00

A pattern that helps me during Agile enablements and rapid project inceptions is to conduct brown bag sessions on the topic that I am about to introduce in the following few days. One such presentation is on Agile User Stories. I will try to keep the content updated with every new nugget of knowledge that I gain. Until then, please do not hesitate to drop me a line if you have comments/suggestions/questions.

User stories

View more presentations from udairaj.

Agile Pathologies: Anomalies in Agile Practices

2010-08-13T07:30:00.000-07:00

Pathology is a strong word and a bold one to use to deliver the idea I intend to. An interview candidate at ThoughtWorks at the time pointed it out to me during our one on one. He said, "Do you really use that word in front of your clients?" The idea behind the use of this word is to focus on the emotional and behavioral challenges that are frequently observable during Agile enablements and transformations. For lack of a better word, it is 'pathology'. Although pathology indicates existence of a science behind its eradication, I consider it an art. A presentation on the topic is available at the end of this post..

Exhibited by individuals:

ScrumMasters don't speak in Daily Scrum or Standup: In a few of the coaching engagements I encountered ScrumMasters who didn't give any insights into what they were doing for almost a week at a stretch. In one instance the ScrumMaster said to me, "I am a ScrumMaster, I am not supposed to speak in a Standup; it's a Team's meeting".
Lone Wolf Syndrome (anti-pairing): Pairing comes across as an invading concept to many. It seems to threaten some and slow down others (even though only for a short while). Egos are hurt and disagreements on implementations arise. In a short duration experiments with pair programming evokes all the reasons why most software developers are lone wolves; there's too much talking, difficult questions are asked about the design decisions, peer pressure to delivery something everyday is sustained and flexibility during the work hours to indulge in non-programming work is substantially reduced. Most importantly, the glory of having delivered a piece of code single-handed and a chance to be a hero doesn't exist any more. All these are good reasons that further fuel the lone wolves.
Ineffective neuro-linguistic tendencies: How many times have you encountered someone in a meeting was asked an open ended question that triggered a rambling from the other side? How frustrated have you been when a key decision maker asked a closed question and did not assess the root cause of a problem? Have you witnessed a meeting which dragged on just because no one asked reflective questions? Have you ever read user stories or requirements that are sprinkled with nominalizations or generalizations or unspecified nouns and verbs? I have, over and over again.
Emotional block to learning new concepts (e.g. metrics, estimation scale): Some external influence has set an expectation that there is a test or a quiz following the introduction of this new concept. To some it is disappointing that there is usually none. To others it's the anxiety of using a new approach in their routine work and an expectation to succeed with it. There's also a third category where some reject the notion of a new ideas because they don't see a problem with whatever they currently use or simply latch on to old ideas a little too tightly.
Fear of Analytics and Usage Statistics: This is easily to spot in the Product Owner (PO) group. It is not uncommon to find requests for features that are a 'pie in the sky' with few indicators that justify the demand. Quite often it is not difficult to access these statistics, but they are deliberately hidden by POs. There's a fear of embarrassment, "How would I look in the face of poor usage statistics of the features that I fought for tooth and nail a few releases ago?" or, "I don't want IT to question my PO skills with software usage statistics".

Exhibited by Teams:

Broken Windows: I use this term metaphorically for an imagery. Broken windows theory suggests that if problems are not fixed as they occur or corners are cut and not corrected they will become examples for others and further deterioration will ensue. In software development this may mean writing poor quality of unit tests or avoiding them or bypassing them during build development. It may mean poor quality of narratives or constant rework for developers if critical feedback loops are short circuited. Unfortunately, all of these examples are real-life that plagued their teams.
Acceptance of Technical Debt: Technical Debt is an acceptable notion on Agile teams. The slope, however, gets slippery when technical debt is ignored. In the race to get releases out on a predetermined schedule or to now lower the throughput of software to production teams seldom take a break to get rid of this debt or even refactor.
Release planning without Analysts: The ivory tower thinking of most program managers and project managers come to visibility on topics related to project finances and resource management. I always wondered where it all started and zeroed in on release planning. Who contributed to the software release map? It doesn't surprise me anymore to know that quality and business analysts were not involved. PM ran the show there with a few high-level stakeholders and agreed to a fictitious timeline with some events sprinkled over it under pressure from authorities up top.

Exhibited by Organizations:

Squirrel Agile: Imagine a squirrel crossing a street. Imagine undergoing an Agile adoption. There are, in some instances, similar patterns - let's do this new thing, keep doing it, don't do it, OK do it, NO get back to what we did earlier. Halfhearted, uncertain, knee-jerk driven, fear instigated decisions that lead to a hodge-podge environment are too common. The stink over the mess is a proud declaration by some managers that they have their own flavor of Agile. That's a problem. Command and control tendencies, assignment of resources to multiple teams, setting up teams that are function specific (analysis, development, and testing), tracking capacity utilized are often the the first signs of squirrel agile.
ScrumMaster Certification: The newest emerging trend is to hire certified scrum masters and professionals. There's nothing wrong with it except that most of the Agilists that I have worked with and talked to don't care for these certifications. On the flip side, a lot of certified scrum masters haven't even once been on Agile projects. These certifications, in my opinion, are dangerous; they create an illusion of experiential knowledge and arm the attendees (that's what most so called trainees are) with enough vocabulary to make them a risk. Yes, risky, because the traditional mindset is prevalent and practices are rampant under the guise of Agile.
Seeking an Agile Playbook/Cookbook/Rulebook: As an Agile Coach one of the requests often made to me is, "Can you leave us with an Agile Cookbook?" A steadfast belief that Agility will flourish if there's an Agile operator's manual warrants a discussion. But believing that Agile is esoteric and a rulebook as opposed to actual practice will help adopt and sustain Agile is an untenable notion.
Agile without being Agile: I once consulted to a client that had a regimented release calendar - two releases a year. Their entire technical, political, and bureaucratic infrastructure was designed and tuned to serve these two releases. The discouragement and hindrance in this environment was that all but two of the stakeholders perceived a great threat in exploring ways to redesign or tweak the processes. Even the optics of trying to do so, to some, was a risk too big to take in the institutionalized environment where adherence to these processes was rewarded.
Strong Identity (e.g. "We are a metrics company."): Who doesn't love metrics and who doesn't have a strong identity? Some enterprises have a strong folklore culture that propagates such fanciful identities. Management gurus may argue that these are must have characteristics to build a successful enterprise. I agree! Let them, however, not become roadblocks to change. The problem occurs when strong identities become roadblocks to pragmatic and rational change of mindset that Agile predominantly is. Metrics is a good subject. Some organizations and project managers are obsessed with them. Too much time is spent on tracking indicators that really don't indicate much. If someone is trying to plot a polynomial regression graph for a burn-up trend projection when a linear regression usually suffices, you know you have a problem at hand.
Nominal Product Owner: Recently I was working with a company that is designing a new product and has an aggressive schedule. Some of there people are new to Agile, including the President of the company. As we were presenting our findings and plans to the team the President interjected and asked us a lot of questions about the level of details we came up with, our confidence in what we found out and understanding the domain and the intent of the product, roadmap and our ability to deliver on time. Those were all excellent questions and we are glad that he asked them. He then switched his attention to the product owner and asked her many questions. Those included questions around her comfort and confidence in working with us, product boundaries, depth of product exploration exercise that we did, etc. Gist of the story; the PO was the anchor in the situation. She was entrusted with a market leading product and the responsibility to get it out of the door in time. Period. That incidence made me realize how underpowered and untrusted some of the other POs were in their organizations when I worked with them. They were titular Product Owners.

There are more pathologies. The above mentioned are harbingers. The intent of this post is not much different from the last few - spread an awareness of what plagues agile adoptions and to prepare people to spot these anti-patterns as they develop.

Agile pathologies

View more presentations from udairaj.

Image taken from: http://farm1.static.flickr.com/191/480869012_f1493aceb2.jpg

Agile in Three Words: An Attempt at an Epigram

2010-07-12T17:00:00.000-07:00

As I spend more time with leadership at some of my client organizations a theme has started to emerge in our conversations. An aspect of that theme is the curiosity about the preconditions of Agile; "What is the sine qua non of Agile?". A variant is the line of questioning on what I look for in an Agile environment. My summary of Agile in three words: Creative Empirical Mindset. Here's what I mean:

Creative: Regardless of the current stance, people leading agile adoptions are, usually, after a new approach to deliver business value. The only realistic and sensible path forward, quite convincingly to me, is to break the routine. This may include, for instance, suspending the division of labor while approaching problem solving within teams. In the interest of getting rid of the historical hangovers of the past, highlighting the unproductive and unfriendly practices, new ideas, and objective feedback are often the best place to start. Unfortunately, the pressure-cooker environment that has come to be in businesses, the approach to "manage" people, and the sophistication of services provided seem to hint at specialization in skills, maximizing their utilization, and staying focused on the "best practices". This has left little room for tolerance of mistakes, missteps, or adventures, which are expected byproducts of creativity. A valuable observation in creativity I have come to admire, watching a few good leaders in the field,is to stop being antagonistic to those who are.

Empirical: This is one of the more subtle concepts to tackle in the Agile sphere. Agile or not Agile, empirical approach is utilized in a lot of environments. Agile empiricism is contextual to creativity and to the practices being followed by team(s) on a daily basis. Empiricism in an agile environment is the lever to direct and better utilize creative aspects of Agile and for the team to have its own self-awareness of sorts. Is the team able to, motivated by a desire to continuously improve, reach empirical conclusions?

Mindset: In contrast to a process, which tends to codify a sequence of steps in order to reach an end goal, Agile teams are driven to confronting novelty and improvise. In effective Agile teams that craft software, I have not seen a propensity for processes. There almost seems to be no need for it. Often, as I have noticed, the people engaged in these teams don't need one. They are motivated to deliver a good product and seem to know what it takes to get one built and running. They abhor "process" because it restrains them and injects delays in their work. Most importantly, it takes the very soul out of work, because it leaves little space for the thoughtfulness to prosper.

Now, as a few of my esteemed colleagues have pointed out, everyone has their definition of Agile. I'd be curious to know what is yours.

Agile Abstinence: Forbearance in Leadership

2010-07-07T16:57:00.000-07:00

"When should we avoid Agile?" At my last client the President of the company asked me, "When does Agile not work?" It seems that a blog post is on the topic may be useful. Given that Agile is a continuum of an effort to foster communication (technical and social), increase collaboration, drive efficiencies and increase quality, I understand and translate these question as, "What are some of the significant challenges and barrier to Agile adoptions and sustainability?" I want to call out those leaders who understand and acknowledge these challenges, set right expectations with their sponsors, and take a cautious approach forward. And hats off to those who decide not to do go down the route until they get the right technical, social, and political infrastructure in place. Back to the question; factors that pose significant challenges to agile adoption are:

Dedicated teams(s): Agile teams thrive in communication rich environments. As communication suffers chaos starts to creep in. A lack of affiliation to a team or perceived split to many teams makes it worse. Team members do not bond well with each other and commitments remain shallow that result in poor quality of outputs. Though many factors contribute, this drop in quality is, in most cases, correlated to lack of communication. Agile adoption becomes an uphill battle and ultimately becomes counterproductive. Utilization metrics are a political heavyweight and sway many decisions in favor or "resource" split between different teams. Poor communication follows not long after.

Big Opaque Software Frameworks: In context of teams that produce software, ownership, access and control over the code being written is vital. If developers can't modify this code base to suite their needs and hook various tools into it they can't really do much. Basic practices that contribute to stability and quality of software like Unit Testing are hampered. Extensive upfront design becomes mandatory in rigid software platforms. Big ERP and CRM applications fall into this category.

Systematize Agile: Systematization of Agile adoption within an organization are laden with a high risk of being detrimental to its success. It curbs the "inspect and adapt" nature of Agile. Agile adoption will become painful and disappointing if it's template-ized along the lines of some prevalent industry certification models, specially the ones that have over emphasized/specified processes and documents.

Untamed Team Distribution: Lack of interaction between development team and business stakeholders adversely impacts the feedback cycle and affects quality of the product. Development velocity takes a hit and ultimately feedback cycles lengthen to a point where either rework increases or a team's progress is adversely impacted. Agile leaders in the industry have figured out approaches to make Agile work in distributed environments but only when a team's distribution is purposefully designed, i.e. they have the luxury to choose the people on the teams, their physical location or have a say on the rotation schedule of people between locations and teams. The persuasion to form teams with individuals that are dispersed between multiple locations and "staffed" to be available might backfire and lead to woefully suboptimal value.

Right sponsors: Agile practitioners who typically focus on consulting in Agile enablements or organization transformations often debate about a strategy to spread agility within the organization. Top-down and bottom-up camps exist. I think, regardless of the approach, the common denominator has to be the change of the traditional value models. Adherence to best practices and business processes is still rewarded. Agile enablements are usually not served well by these practices and processes and call for a change. If the leadership of an organization is not yet personally ready to sponsor that risk taking the outcome is fairly straightforward to guess; bad news and a bad aftertaste.

Right people: Some of my previous posts talk about the people side of Agile adoptions. It's the people that matter; more so in Agile than any other transformation that I have seen or read about. Agile practices are extremely people focused. The orientation of systems and decision making is designed to make it an extremely fast paced learning environment that is heavy on communication and busy with collaboration. It almost warrants frontier individualism of teams.

It is likely that this post may cast a doubt about Agile and its fit for certain kinds and sizes of organizations. That's not my intent. It is merely to highlight that pioneers of Agile are now starting to experiment on the above stated fronts. Some leaders in the industry are aware of this trend and choose to wait and let the Agile community learn valuable lessons before they adopt it. They don't fear being cast as late majority or even laggards. I have quite a bit of admiration for such hardheaded and matter-of-fact decisions. Image taken from: http://wizard.webquests.ch/pics/upload/98/frontier_400.jpg

Building an Agile Ship - A Taoistic Approach

2010-01-26T06:00:00.000-08:00

Big challenges in building agile teams, in my recent experiences, have come not from lack of Agile knowledge on team's part. They have come from a lack of co-operation that the team members have demonstrated within the team. Seemingly unrelated frustrations like team member's tuning out of critical meetings, not being able to learn new concepts, and even bigotry can be attributed to lack of co-operation. Strategies that I have successfully utilized to increase cooperation, which comes at premium, are:

Focus for Agile education and practices should be on all the roles including managers. By design, most focus of education and coaching should be on hubs that have the most nodes connecting to them. Those are typically managers in teams. In addition to setting the right precedent of leading by examples, managers then set the reciprocation cycle in motion.
Select an Iteration Manager (IM) who sees the role as a challenge, views it as a progression, and is an early adopter of new concepts in general. This will keep the energy level high in the team, and catalysis will keep the team going.
Choose a person that is closest to the team and is liked the most in the team as the IM. In cases where outsiders are the IM, the role should be transferred to one of the team members as soon as possible.
Keep the team size as small as possible. Small teams are most likely to exhibit voluntary cooperation, which increases as communication increases.
Consider a person's personal threshold to adopting a new mindset. It is usually difficult to enable a team of 15 people for Agility with one Agile coach. A few coaches interacting with the team as opposed to just one or two is likely to be compelling enough for potential adopters to give Agile a try. Teams should be seeded with enough critical mass of Agilists who can weigh in on Agile topics, demonstrate the benefits, and convince the skeptics.
It is critical to recognize that learning is a co-operative activity. I have discussed the importance of Socratic methods to enable Agile teams in one of my previous posts. If there's not enough bandwidth of coaches, satisfying Agile adoption in a team is unlikely.
Assemble a good team to start on the Agile journey and learn the right lessons; good or bad. It is extremely important to "design" the Agile team as opposed to starting with just any. This is in line with Maslow's "growing-tip statistics". Maslow asserted that it is the growing tip of the plant where the greatest genetic action takes place. He leaned towards studying and focusing on the best. I paraphrase:

"If we want to answer the question how tall can the human species grow, then obviously it is well to pick out the ones who are already tallest and study them. If we want to know how fast a human being can run, then it is no use to average out the speed of a "good sample" of the population; it is far better to collect Olympic gold medal winners and see how well they can do. If we want to know the possibilities for spiritual growth, value growth, or moral development in human beings, then I maintain that we can learn most by studying our most moral, ethical, or saintly people."

These strategies will solve a few key problems that we observe in environments starting to practice Agile. These are environments where the propensity for Squirrel Agile is high. Bad and selfish proclivities like wanting to be Agile without being Agile are common. Other such common regressive behaviors often include:

Free Riding - Some team members get by without participating or working to make teams agile
Lack of commitment - Dismissing Agile from the get go or losing faith too early
Lack of discipline - Teams cut corners and don't follow the agreed upon practices
Lack of initiative - No one steps forward to carry out tasks, e.g. daily standups not held because Iteration Manager was out
Contingent co-operation - I yield this much of my "comfort zone" to you, you cede some of your Agile practices to get my co-operation

Some design principles addressing the above issues that I have followed for Agile teams are:

Define clear boundaries. On one of my projects at a large corporation we drew a virtual garden wall around the project teams. It was clear to every stakeholder which people were in an Agile project and which were not. The folks within were to a large extent insulated from the business-as-usual outside of the garden wall. Ideas still permeated through the wall and people from outside could peek over to see what the Agilists were doing. But it was evident to everyone the teams withing the garden were different and they were experiment with news approaches of operating.
Rules should match the team's needs and conditions. Agile teams should be able to adapt the rules of the game to match their needs and organizational environment. On a project that had unsustainable meeting schedules, we reduced the frequency of some meetings, recommended increasing the details of some documents so that distributed teams can get more of their questions answered. The latter goes against the conventional wisdom of Agile, but it suited the needs of the team.
Individuals affected should be able to change the rules. Agile teams should be able to form the rules for themselves. Changing rules should be a mutually co-operative endeavor; not a decree from senior managers or external consultants. External authorities should respect rights of the team members to devise their own operating principles.
Leverage reputations. Reputations are often the most powerful tool to utilize. On one of the teams that I worked with, I went out of the way to find out who's respected and valued for what in the teams. The next obvious step was to connect their passions with project tasks that needed to be accomplished and had them sign-up for these task in the team's and stakeholder's presence. This practice was then transitioned to the retrospectives and sustained there for iteration level tasks.

The temptation of changing a team and radically altering how it works is too great for the Agile coaches to resist. It gets complex as the purview of a coach increases and the size of the organization gets bigger. There has to be a reason, almost always, why seemingly bureaucratic processes exist and are followed in client organizations. Often such elaborate "processes" are the communication mechanisms and the eyes and ears for the leadership into what's going on in the company. Such processes are central to governance. It is wise to acknowledge the fact and evaluate how it can be adapted (not rooted out) to accommodate Agile projects. An approach to introducing and experimenting on Agility with this mindset is better suited to generate co-operation from the traditionalists in large environments. Image taken from: http://commons.wikimedia.org/wiki/File:Tao_character.svg

Humanics - The Next Frontier of Agile Adoption

2009-08-31T09:55:00.000-07:00

Agile is a reusable and, for most part, a transplantable strategy. It's easy to replicate, simple to understand and well socialized. It is comforting to those who have successfully adopted it. Yet, to others it is elusive, at best. The discrepancy between adoption rate and success rate is stark.

Pockets of Agility Numerous Agile adoptions are identical but few bear success. Reasons are simple; change agents ignore the "humanics" and are often reluctant to make Agile the central philosophy of the enterprise. Pockets of experimental runs produce some compelling results that can be attributed to the purposeful rigor that Agile instills. Some observations about Agile:

Its rigor is almost an asperity to some,
The "just do enough" philosophy seems counter intuitive to software "engineering", and
Its lightweight nature makes the optics of Agile ad-hoc.

For the above mentioned reasons, it is sometimes difficult to scale. To make matters worse, several Agile adopters still lack the will to formulate a strategy to scale. Organizational momentum of multi-year product development plans and cultural inertia are formidable challenges. (Interestingly enough, it is these very environments where I have also seen Centers of Excellence and Communities of Practice on Lean. This goes back to the problem of disconnect that still exists between Agile and Lean.)

What's in it for me?

The root of the problem, I think, is that Agile proponents haven't clearly answered the question "What's in it for me? Why should I conform?". The business case for Agility attempts to leverage the "better quality working software faster and frequent to market" and "adaptability" propositions. So What? What's in it for me if I belong to a testing organization in a ten thousand people organization that is regulated and has little competition? Why should I care about Agile? This is purely a "humanics" issue. And, it shouldn't be a surprise that even the C-suite has the same question. They didn't "grow-up" with Agile, afterall.

Success requires Heterogeneous Audience

A critical insight that Agilists, including me, get into and grasp a little late is the desired composition of stakeholders to succeed. This vulnerability has single-handedly and more definitively caused more Agile adoption failures than anything else. The pithiness of Agile value proposition hasn't reached the board rooms yet, as Lean in manufacturing has. It'll be a while before Agile recommendation are dusted off and looked at seriously. In the interim, the Agile community is focused and busy honing the mechanics of Agile. It is steadfastly employing the technical infrastructure of Agile in project teams and training the minds of future. Projects are still aborted and hopes are still dashed. The onus on the Agilists now is to come clean on the extent to which Agile can provide benefits and what to realistically expect in absence of or inadequate "air-support".

The Psychological Art of Agile

As mentioned in one of my previous posts, Agile has ceased to be a technical challenge. Growing aspects of its social challenge pose a bigger uncertainty and pale the technical complexities. The current frustrations aren't as much around the capability development and mechanics of Agile as they are about the value system. Discussions on scaling are heavy on the people side of issues. We are slowly seeing a trend where sustaining Agile is becoming a psychological art. There are some people who are cut out for Agile, others simply are not. "Agile is not a skillset, it's a mindset", as one ThoughtWorker says it. With that lay of the land the question becomes even more important - how do we scale? What's the people strategy for those who don't have the Agile disposition? A good deal of intelligent and responsible attention has to be given to why some hold an unfavorable disposition to Agile and how can they be favorably persuaded. The answer, it seems, lies in self-awareness of the teams. 'Self-directed Team' has been a long standing notion in the Agile community, albeit somewhat confusing and misunderstood. Before being self-directed we need the teams to be self-aware of what's unfolding around them; their impact on project(s), where's their stock with the management, and their contribution to long-term technical capability-development. Without answers to these questions teams cannot be self-directed.

Connect team's vision with the corporate vision and tie team members' aspirations to the vision. This would answer the question, "What's in it for me?". Managers should complement the Scrum Masters in ensuring that they clearly communicate to team members what they stand to gain from the transition and the skills they'd build.
Next up, I'd recommend an old trick that works most of the times. Stop selling Agile. Instead, start asking why Agile would not work. Ask it often and induce people to think about it. Focus their attention on Agile as much as possible.
Teach people something about Agile at every opportunity you can find. Remember, focus is power, expectation shapes reality, and attention density shapes identity. Use the powerful conduit of education (conferences, guest speakers, etc.) as a means to persuade. A word of caution here though. There's a stark difference between education and training. Don't undercut your returns by mere training people; it won't last long. To create an environment of learning and bring a lasting change engage industry experts who see themselves as instruments of cultural indoctrination as opposed to just trainers.
There always are some who don't absolutely embrace new concepts and systems. Then there are also a few who just don't get it; like I don't get Quantum Physics. Find these people something else to do. Get the ones who understand and are passionate about Agile on your teams. Yes, teams are formed; they don't happen by chance. Don't be timid about team formation. This is a controversial thought employed too often and creates havoc for so many careers. More on it in later post(s).
Don't go piecemeal with Agile Adoption on a project. There's no such thing as setting up the right Agile management structure (Scrum) first and then introducing the engineering practices (if at all on a project). This will frustrate people and signal a half-hearted and fearful leadership style.

This list is far from all-inclusive. A cursory study of the partial list is sufficient to support the argument that planning for success should prepare the participants to deal with variety of mental states, outlooks, and behaviors and not just tools, technologies and processes.

Conclusion

Agile has come a long way in the last decade. It now has a foothold in the mind of leaders, innovators, and strategists. It's popularity is growing, but so is the list of failures with Agile adoptions. The long trial-and-error phase is over and we are entering into a phase of trial-by-masses. Soon (5 years) the polarity of Agile acceptance will increase manifold - a quasi-official product development approach at some places and banished from others. Illusions and myths will follow. Humanics will, very likely, emerge as a pivotal factor. Agile adoptions with a pure-play technical focus will languish unless the change agents demonstrate good knowledge of the accumulated humanics lessons and leverage them. Image taken from: http://designbivouac.typepad.com/designbivouac/images/dresden_8.jpg

Mindful Change - Beyond Behaviorism and Humanism

2009-01-08T11:10:00.000-08:00

My last post discussed steps to sustain the goodness introduced by a transformation. As an abstraction, introducing Agility is an organization transformation (OT) process - an important one in software industry. The famous trifecta of any OT initiative is People, Process, and Technology. People first!

Leading people to change in order to transform an organization into a more efficient, productive, profitable, pragmatic, and agile business is tricky and often left for the very last. At best, I have seen managers read and recommend literature that deals with behavioral science - psychology, organization theory, and sociology. I always felt that this is not enough, although far better than not being cognizant of or sensitive to people issues or using brute force for business transformation or in OT.

Recently, I read The Neuroscience of Leadership , which is an excellent primer on the next frontier in organizational transformation - cognitive science. This writeup concludes that, and I quote:

Change is pain. Organization change is unexpectedly difficult because it provokes sensations of physiological discomfort.
Behaviorism doesn't work. Change efforts based on incentive and threat (the carrot and the stick) rarely succeed in the long run.
Humanism is overrated. In practice, the conventional empathic approach of connection and persuasion doesn't sufficiently engage people.

The next three points, which can be treated as prescription are significant. Again, I quote:

Focus is power. The act of paying attention creates chemical and physical changes in the brain.
Expectation shapes reality. People's preconceptions have a significant impact on what they perceive.
Attention density shapes identity. Repeated, purposeful, and focused attention can lead to long-lasting personal evolution.

What does this mean for OT practitioners?

The first message is that behaviorism and humanism can be and should be leveraged only so much. Second, if change is pain then it should be done as fast and as quickly as possible. I prefer an orderly big-bang; a carefully spreaded out step-by-step rollout will not only delay the reap but agonize the people too.

Onboard OT teams with 'right' people. There's those who can see themselves operating in a new and better environment, and then there's those who are extremely comfortable with status-quo. The latter are a detriment to change initiatives.

How could change be lead by people who don't know why they are changing and for who? OT leaders and participants should also nurture a vision to make their services/products more competitive. The expectation to make services/products more appealing for consumers and the business more efficient and productive is essential for OT success. Also, include people from different functions of the business - marketing, accounting, project management, customer service, to name a few.

It takes multiple sessions/workshops for people to understand and remember concepts. The root cause is not participant's IQ but their lack of focus and sometimes the learning material not being insightful enough. 'Induce others to focus their attention on specific ideas, closely enough, often enough, and for a long enough time.'

I don't know of any successful transformation that was a one man show, even if it was glorified as such by media. Transformations and turn-around are executed by teams that have a critical mass, the appeal within the organization, and the know-how of the business. Hence, OT initiatives will not be successful unless change is perceived to be necessary by others. Therefore, embarking on a OT journey can be a decision that a CXO can take, but the demand has to be generated from the bottom first. Invest in creating an environment where this demand gets generated. A good consultant would know how to get there.

Image taken from: http://watarts.uwaterloo.ca/~celiasmi/images/brainclimb.jpg

Recipe for Agile Sustainability - Don't Forget Process Irreversibility

2008-12-11T17:00:00.000-08:00

So, you adopted Agile in the past. It was also a success by your yardstick. Sustaining Agile transformation, however, has proven out to be a challenge. There's also challenges with scalability.

It's not an unusual challenge. As with any change process, Agile transformation requires checks and balances with an eye on building process irreversibility. Only then would I consider an Agile transformation/adoption to be really successful.

Balanced Teams

Amongst the building blocks of Agility are Teams. An often overlooked component of teams are people and their inclinations. There's often members in Agile teams that are of traditionalist persuasion (some of my colleagues call them Skeptics, although I disagree with the term). They can't be convinced and changed despite overwhelming evidence (which distinguishes them from Skeptics); that's what makes them traditionalist in the first place. The idea is to balance the Agile teams out with Generative Thinkers - those who can model their business and processes with innovative practices.

Balancing teams out is the first step towards process irreversibility. Some other steps are:

Individual Retrospection: In one form or the other a question I often encounter is, "What'd you focus on in a team that is already Agile?" Individual Retrospection is always top on my list and is an offshoot of sustainable pace. It is not the same as team retrospectives. If a team has a sustainable pace, its members will have time think about what they are doing and how they can improve it. Individual retrospection is highly undervalued in the industry and often has a negative connotation. Traditionalists interpret it as underutilization of resources. It is considered elitist and a privilege of managers.
Meeting Facilitation Training: Sliding back into old ways of doing things is common. Teams often loose steam which results in bad behavior creeping back in. Meetings are the first to suffer. Lack of attendance, lack of focus, too many meetings, and a general confusion about the objectives of meetings are some of the first signs of old ways creeping back in. Team members trained in meeting facilitation skills and techniques prevent this backsliding.
Metrics and Reports: As in any change management system, there's got to be reason why Agile was considered. Those reasons should be tracked using some metrics by the management. Agile also recommends some metrics that should always be tracked, even if they were not on management's radar. Success of Agile adoption should be measured by these metrics and nothing more and these should form the Agile Dashboard by which business should be run.
Agile Evaluations: A good management practice associated with Agile rollouts is periodic Agile evaluations. The focus of the such an evaluation is on different aspects of Agility, e.g. Responsiveness, Simplicity, Configuration Management, and many more. .
From Flavor of the Month to Business As Usual: The more seasoned a team member is the more compelling it is for them to continue being who they are and to follow practices that have made them successful. There's quite a few other team members who want to be like these successful Einsteins. Emulating their stances is only natural for the less experienced. That's the DNA of a corporate culture. Convincing the Einsteins that Agile is not a flavor of the month but here to stay and soon to become a norm, is paramount. This message should be loud and clear.

Agile allows team members to participate and control their course. At the same time it requires discipline. There's no magic in Agile that makes it ceaseless, unless process irreversibility is intentionally designed for its adoption.

Consulting Tools - Thinking, Modeling, and Inquiry

2008-11-24T09:43:00.000-08:00

Ever wonder what tools make a consultant effective? It may be a long list. If you read The Opposable Mind - How Successful Leaders Win Through Integrative Thinking, it is obvious that consultant would benefit from most of the process techniques that Roger Martin talks about in this book. The three that stood out for me are:

Generative Thinking - Pondering along the lines of 'what might be'
Causal Modeling - What causes Something, and what's the purpose of that Something
Assertive Inquiry - Asking questions that encourages dialog, rather than shut it down

The Process of Thinking and Deciding is a good revelation of how a lot of us reach decisions. Recollecting my interactions on past engagements, it is quite obvious that these patterns have serviced me well. I was, until now, unaware of their interdependence and collective power.

Going forward, it'll likely serve me as a good framework for interviewing candidates who aspire to be consultants. I have never been subjected to an interview myself where someone tried to assess these skills. That clearly demonstrate how much little we understand and value the utility of these tools in our professional lives, or so it seems.

Image from: http://www.childcareaware.org/images/category_icons/tools.gif

Got Agile?

2008-11-04T04:24:00.000-08:00

VersionOne released The State of Agile Development report for 2008. A few days ago I wrote about barriers to Lean implementations, which is available here. It is interesting to see that the barriers to further adoption of Agile are not very different from those of Lean implementations. 44% attribute it to "General Resistance to Change", 45% to "Ability to Change Organizational Culture", and 32% to "Management Support".

To avoid stalling, as I read it, it is important to concentrate on the soft issues as much, if not

more. Experience and know-how of Agile technicalities is not sufficient to ensure success.

It seems that Agile has reached a point where it has ceased to be a technical challenge. Agile is now a cultural challenge. Either address the fundamental issue of resistance to change, be ready to get mediocre returns for your buck.

Lean Implementation - Skills Needed?

2008-10-22T12:43:00.000-07:00

A Lean Enterprise survey in 2007 reflected that about 36% of lean implementations face middle management resistance as an obstacle. Approximately 28% face employee resistance. Lack of implementation know-how came second at 31%.

This is, of course, a survey conducted amongst organizations engaged in lean production. Humans being humans, I would guess that these numbers won't be very different in Software and Services industry. Basically, any change program involving humans will face challenges that are similar in nature and magnitude.

So, what skills do you think a change agent would need? Seems to me that technical knowledge is only a third of the solution.

The Episodic Sprint

2008-09-05T18:00:00.000-07:00

One of the first thoughts on hearing the word Scrum - 4 weeks to a Sprint. To some this is music to ears, but to others not so much. And who are these "others"? Usually, it's the Product Owners (PO). While developers want a sprint to be locked out, POs want to be able to add/remove/swap stories in it. Scrum's answer to that is simple - avoid it. If you can't avoid it, flush the sprint and restart. The inspiration behind that recommendation might have been to discourage changing the sprint in-flight.

Where's the Agility? Isn't a locked sprint bit contrary to the whole concept of agility? What's the point in locking out if the underlying philosophy is to be able to adaptive? Clearly, it's a conflict of interest between the developers and POs. One way to avoid it is to reduce the sprint length, to let's say 1 week. Now, this may be a mighty fine deal for the POs, but it not always the case for developers. One week may come across as a bit rushed to them to produce anything meaningful in some contexts. So, what's the best way out.

Multi Episode Sprint A good compromise can be a half-locked sprint. In a four week Sprint plan and lock the first two, plan but keep the last two open to changes. One of my colleagues at ThoughtWorks calls it an Episodic Sprint. If there are changes mid sprint, have a sprint planning meeting after the first two weeks to re-plan the remaining two. Episodic sprints, in my opinion, are a step towards creating a software development environment that prevents itself from being fed half-thought through and low priority stories but still accommodates for genuine changes. For teams that are just starting Scrum, I would highly recommend Episodic Sprints.

Opportunity for Increased Agility

2008-06-09T08:14:00.000-07:00

Being a big fan of Agile, I didn't miss the opportunity to present my thoughts at the Microsoft Community Summit - 2008 in Orlando, on June 7. Thank you all for your eager participation. I throughly enjoyed the questions. Based on your feedback and the questions you asked, I have modified the presentation a bit. It is available at http://www.slideshare.net/udairaj/rapid-project-inception-456123 Please do not hesistate to contact me at rsingh@thoughtworks.com with any questions, comments, or suggestions.

To Re-estimate or not to Re-estimate

2008-05-14T22:00:00.000-07:00

A project is incepted with a story list that has all the stories estimated. The team has completed 4 iterations and there are 8 more to go. The team also has usual churn of people. Are you in favor of or against re-estimating stories during next sprint planning? Practioners are on both sides of the fence on this one. Some recommend re-estimation and some want to stick to the original estimates. A colleague of mine recently explained why he is not in favor of re-estimating. He said, "I don't want to have to explain to the project sponsors why the project estimate just changed from 133 points to 97. Do you think the scope has changed?" That was a very insightful discussion. He then said that if the team is not finding the big stories as big as they initially thought, it won't matter. That simply means the team is now burning more points of a larger scope number. This will proportionally be the same as burning less points of a smaller re-estimated scope. Re-estimation is a tough thing to convince people on. I still see a huge benefit in it.

The idea of re-estimation is not about lowering or increasing the numbers; it is about estimating the relative size of the stories.
The stakeholders/sponsors, ideally, should not be concerned about total point scope. This is an internal number for the Dev team. Sponsors should just be concerned about the rate of progress towards delivering a product.

As a sponsor, I'd be more interested in the secondary estimate, i.e. time. When will my product be ready for release? It really doesn't matter so to me if this scope is estimated at 150 points or 800 points. Re-estimating the stories should be encouraged because it:

Keeps the relative size of stories up to date,
Makes it almost mandatory to revisit the release plan, and
Promotes conversation.

Relative size is a big thing to watch out for in situations where new stories are added or existing ones are split. The reality of agile greenfield software development is that the initial brainstorm hardly ever reveals all the stories. Total effort, as estimated, at the beginning of the project will most likely change (increase). An initial estimate that is not changed with the lessons that have been learnt in the last few iterations is not acknowledging that:

Work done in the last few iterations can be leveraged,
Assumptions with initial estimates may have changed.

Typically, teams start with developing the simplest functionality first. Let's assume that Story A is the simplest functionality and is 1 point. And, the initial estimates had story B estimated at 3 points thinking that this is three times the size of A. Why would I not want to re-estimate B as a 2 if I now know that is twice the effort of A and not three times the effort?

One of the biggest benefits of re-estimation is that it reevaluates a team's progress towards the end goal and indicates if you are on track or not. Not re-estimating will increase the probability that one of the stories a few iterations down with an initial estimate of 2 points will now take 5 points worth of effort. There may be many more such sitting in your pile of stories. Example Problem: Let's say that you have a 1000 sq. ft. backyard that needs to be landscaped and upgraded with a water fountain. You hire a contractor and (s)he gives you the following story list:

Tilling out existing grass - 2 pt
Discard old grass - 3 pt
Transporting grass to backyard - 1 pt
Laying out and setting the grass - 4 pt
Edging the grass - 1 pt
Post installation cleanup - 2 pt
Fountain Installation - 2 pt

That's a total of 15 pts. Your contractor also tells you that last time they did a similar backyard it took them a day to till and clean (stories 1 and 2). Based on that the plan will be:

Day 1 - Story 1, 2
Day 2 - Story 3 , 4, 5
Day 3 - Story 6, 7

You as the sponsor/customer now have a plan and expect the backyard to be ready in 3 days (iterations) assuming a 5 pt velocity based on the contractor's past experience.

Work starts, and you now request the contractor for two new things. You want the lawn to be leveled in a different gradient and you also want the soil to be fertilized. These are two new stories that get added to the story list.

While tilling, the contractor also finds out that the soil has lot of gravel and stones in it. Scenario 1: No Re-estimation When there's no re-estimation, the story list will likely be as under. The team will estimate the new stories.

Tilling out existing grass - 2 pt
Discard old grass - 3 pt
Transporting grass (sod) to backyard - 1 pt
Laying out and setting the grass - 4 pt
Edging the grass - 1 pt
Post installation cleanup - 2 pt
Fountain Installation - 2 pt
Re-level lawn - 1 pt
Fertilize Lawn - 1 pt

Total scope is now worth 17 points. Based on a velocity of 5 pts. the team will sign-up for stories in the following order:

Day 1 - Story 1, 2
Day 2 - Story 3 , 8, 9, 4A
Day 3 - Story 4B, 5, 6
Day 4 - Story 7

I split story 4 into 4A and 4B, both of which are 2 pts and they encompass laying out and setting grass in half of the lawn.

From the plan it seems that the team will take 3.5 days to finish the job. However, story 3 & 6 have not taken into account the fact that now the scale of the problem has changed. It is just not cleaning and hauling grass, but also gravel and stones. Scenario 2: When we Re-estimate When we re-estimate, the story list will likely be as under. The team will estimate the new stories.

Tilling out existing grass - 2 pt
Discard old grass - 3 pt
Transporting grass (sod) to backyard - 3 pt
Laying out and setting the grass - 4 pt
Edging the grass - 1 pt
Post installation cleanup - 4 pt
Fountain Installation - 1 pt
Re-level lawn - 1 pt
Fertilize Lawn - 1 pt

Total scope is now 20 points.

Story#3 is now 3 points because the team just figured out that transporting sod to the backyard in absence of a wheel barrow is not 1 point but 3 points. Story#6 is 4 points because post installation cleanup is not just grass and dirt but also gravel and stone cleanup, without a wheel barrow. Story#7 is now 1 point because we just gained plumbing skills and found a water pipe running in the yard, closer to the fountain.

The new plan is:

Day 1: Story 1, 2
Day 2: Story 3, 8, 9
Day 3: Story 4, 5
Day 4: Story 6, 7

Traps of Not Re-estimating

When we don't re-estimate it seems like we can finish the job in about 3.5 days. If the Product Owners request additional scope of 2-3 points, I would have no problems accepting it. My plan tells me that I have a little over half the day available.
A new story estimated at 1 pt should roughly be the same as an existing story of 1 pt in effort. But it won’t be the case here; at least it won’t be reflected in the metrics. The idea behind agile project metrics is to make knowledge very explicit. Not re-estimating fails to achieve that goal. Estimate and velocity metrics become very tacit.
As a team member my level of trust in the estimates goes down. There are two 1 point stories, but they are not the same effort. One is a new story and, hence, has a new estimate, whereas the other is an old story and is not re-estimated.
There may be stories that have initial estimates that are much higher than the effort expended on them now. These may not be included in Sprints because they will increase the Sprint sign-up points to go beyond the target velocity. The tendency is to avoid signing up for these stories.
Agile Software Development is also about adapting. Not re-estimating will lead us to become non-adaptive.

On big projects where number of stories for each release easily run into 3 digits, these traps amplify themselves. The benefits dervied from re-estimation may not always be so obvious, but they for sure increase the level of comfort and confidence in the team.

Picture taken from: http://www.stellman-greene.com/blog/wp-content/uploads/2007/05/schedulereview13.jpg

Analyze on Software Not on Paper

2008-04-30T20:00:00.000-07:00

Let's visit a very common conversation that I have often been involved in or heard of: Q: What's the difference between Waterfall and Agile? A: Agile doesn't involve the upfront analysis that Waterfall plans and invests in. This is probably the first thing you hear in terms of differences between Agile and Waterfall. The follow-up question usually is, "How can you do software development without any analysis?" It starts the classic dialog that a lot of agilists repeatedly have. The Luck Factor How can we really deliver business value without 'proper' analysis? We may be able to deliver some, but it'd just be a matter of luck. That's exactly the inspiration to invest in upfront analysis; eliminate the factor of luck. The temptation to know it all and plan everything is just too much. Sometimes, before you even realize someone reminds you that your planning and analysis is starting to look like Waterfall. Not planning, I think, is wrong. Not analyzing is a blasphemy. You are wasting money and time if you are not planning and analyzing. But if its all on paper, powerpoint or visio and planning your software to the Nth possibility you are most likely about to run into a lot of potential waste. Release Zero The solution to this paradox is to have a release of whatever you are tyring to build as soon as possible. Get that extra-lean yet functional piece of software out to your small test-user base ASAP. A colleague of mine termed it 'Release Zero'. In addition to a lot of usability feedback, this would provide your analysts a working system that they can analyze. Scenarios, situations, dead ends, etc. that I as an analyst have come across in actual working software could never ever have been thought of if I were to design theses flows in detailed functional requirement documents and system design documents. The stretch of imagination needed to design a good system on paper becomes so thin and flaky that it starts to consume extraordinary amounts of energy and time to make them useful. So, do just enough, think only so much ahead in time. Before you proceed any further on that theoretical trajectory, get it built. Do your analysis on this release and iterate further. Example Imagine designing a content management and publishing system where a user should be able to:

Create article, etc.
Publish, revise, republish articles.
Rate and comment on articles.
Search on articles
Provide sneak peak into some work-in-progress articles to readers.
Workflow between writers and editors.

This can prove out to be a very complex system to design if we introduce the concept of user groups. i.e. a group of Writers, Admins, etc. in addition to the Readers. Now let's say there's another user group in it called Classified. And let's say that this is a group of users that writes very sensitive information that shouldn't be leaked to the rest of the publishing house and certainly not to the readers before the due date. Imagine how complex the analysis can get. Content should be available to a certain group for editing before the publishing date, but to others after it has been published. Search should not return classified material or should return only parts of it to some readers. Internal editorial comments should not be visible to the readers and/or vice-versa. As an analyst this product would be a big challenge. As I said earlier, my analysis will start becoming flaky beyond a certain functional depth. Decision on functional aspects will start taking long time because product owners, designers, and developers will have very little common understanding. Hypothetical and imaginary usage scenarios will start to consume time. In this situation I'd recommend to start development with a simple model in place. Two user groups - editors and readers, simple search, and basic data privacy and security in place. Once I have this system in place in 3-4 weeks, I can start analyzing on this system and have users test it. In this paradigm, there will be frequent releases and the analysis will be based on the last release. It may or may not be available to the end users yet for feedback. It won't be a surprise if a lot of the current requirements may not be requirements anymore 3 months down the line. Having a working system around to play with will likely make some requirements unattractive or not worth the investment. Image taken from: http://www.time.com/time/magazine/article/0,9171,1630556,00.html

Excellence in In-House Software Development

2008-04-21T06:00:00.000-07:00

One of my client groups recently had a meeting in which they briefly discussed what it means to be excellent in software development. The client is an IT arm of a company whose staple is not software product or services.

It was interesting because this group's definition of 'excellence' did not include a few key points. I feel bad for these key points being overlooked. It's probably because my business is software development whereas software is a means to a different end for this group.

Here under are some attributes that would constitute 'excellence' in my opinion. In a software company or a software support arm of a non-IT business, I would strive to achieve an environment of:

Transparency - This could be anything from who's busy doing what to how the past efforts have been impacted the business. It never hurts to update your team on why certain decisions have been made. Transparency is the foundation of excellence.
Problem Solving - Often we find people say that they are problem solvers or that their's is a group of people that solves problems. I am not surprised anymore when on further investigation it turns out that most of them are patching problems up. Solving a problem is a bigger initiative. It, usually, requires bold steps and long-term vision without a greed for short term results.
Innovation - Continuing to solve problem the way you have been for the last 5 years, if at all, may not the best return. How have you, your team, your systems, and your processes become better and more efficient?
Entrepreneurship - Innovation and problem solving often remain in silos. Is there drive, energy, and enthusiasm in your innovators and problem solvers to take on the challenge to weed out inefficiencies from the system? Entrepreneurship usually is a response to an incentive of some kind; tangible or intangible. Create a few to foster it, if you haven't already inherited some.
Solution Focus - Enthusiastic technologists, specially in IT, are very eager to try new products, services, languages, and platforms and want to build their skills in them. Sometimes this is the reason why we find hundreds of applications written in 10 different languages with 4 different database systems. This also happens to be a reason why we also find features in these applications that took months to build but are rarely used by very few in the user community. That happened because it was a cool thing to build. Gist is that, after all, it is not about software. In the end, it's still about a solution to a business problem. It's a tough job to balance the big picture with the innovation.
Investment in Knowledge Sharing - One of the big reasons that high-end IT consulting is such a big industry is because consultants seem to know the latest and the greatest. On a few occasions I have been surprised how much one of the client associates already knew about a certain topic. It was even more surprising to know that in some of those cases the managers knew that a certain employee is very knowledgeable but did nothing about it. Instead, they waited for the consultants to show up and charge high dollars for it. Give your people room, time, and incentive to share what they know with the rest of the community.
Discipline in Action - Innovation, Solution Focus, etc. become the culture only if there's discipline around it. Do it every time and at every given opportunity. Very few people realize how demoralizing and demotivating it is to find out that there's really no rigor around in the culture.

What would you add or take away from the list?

Picture taken from: http://www.gapingvoid.com/excellence224.jpg

Demise of Offshore in an Agile World

2008-04-12T06:38:00.000-07:00

The increasing adoption of Agile software development and management practices is starting to create an interesting dynamics. Agile adoption is not restricted to collocated teams anymore. Distributed projects have also been executed for long using these practices. But offshore projects are now being experimented with Agile. The primary difference between distributed and offshore is that the entire development, QA, and analysis, in offshore project is located away from the product owners/project managers. Another subtle distinction, which exists in the consulting world, is that offshore teams are typically all-consultant teams with little or no client members.

Agile, as practioners recommend and as teams experience, is a very disciplined approach to software development. It also demands a redefinition of the concept of a team. In the agile world a software development team is not just the developers, analysts, and QAs. A team also includes product owners, product managers, and program managers. This is a team of equals and is empowered. Every team member can and should make decisions that benefit the project and propells the team.

Given the team dynamics and interplay required for the success of Agile teams, offshore projects usually struggle a lot. They don't achieve the velocity that the team is capable of if they were collocated or distributed. Physical separation and time zone differences erode the benefits that collocated or distributed agile teams reap. The wastes created due to offshore hurts the agility.

I sometimes wonder what the future of Offshore is. How about offshore consulting? Will the politics and lack of trust that inherently plague client-consultant relationship restrict Agile exclusively to co-located or distributed projects? If Agile is the way to go forward, does that mean demise of offshore?

Image take from: http://www.ispan-tech.com/index.htm

Dispensabilty of a Use Case

2008-02-06T11:55:00.000-08:00

In one of his blog posts, Alistair Cockburn mentiones his preference of Use Cases over User Stories. He makes some very convincing arguments about why Use Cases are better - user stories don't set a context to work from, teams don't get a sense of completeness of the system, and user stories don't indicate difficulty of upcoming work. I agree with the assessment to a large extent. However, I beg to differ on the case that is being made for Use Cases. Use Cases are dispensable. A set of well written stories is all you need to get a picture of what's to be built and where we are in a project. A format that user story proponents have found very useful is the 'As a ......... I Want To...... So That .........' e.g.

As A Registered GMail User

I Want To change my email sender name to accomodate special characters

So That the name can be displayed in my native language.

A collection of such stories is very useful in portraying a picture of what is to be done and the business value it will deliver. Such stories typically stem from scenarios that emerge out of conversations with the end users, business, and product owners. Some folks also call them epics. These epics or scenarios, in other words, have constituent stories. A collection of such scenarios makes a system. I struggle to see why this is not enough to set context and assess completeness.

The benefit we derive not using Use Cases is the speed with which such scenarios can be constructed and the flexibility of verbiage. Yet another interesting aspect is around the politics of Use Cases. It is not uncommon to find careers built on them. Use case modelers, as they are typically called, have managed to introduced a layer of seemingly very complex set of activities that struggle to keep pace with the change in requirements. This causes nothing but delays.

For a better clarity of relationships between user stories and scenarios, I encourage you to read this.

Agile to Lean Roadmap: Rapid Project Inception

2008-02-02T17:17:00.001-08:00

This is the presentation I made at South Florida Code Camp '08. It's about Rapid Project Inception and why the Agile community should focus on both Upstream and Downstream activities to make a transition to Lean. If you have any questions, please feel free to comment or drop me a line.

Agile to Lean Roadmap

2008-01-28T05:31:00.000-08:00

Recently, I wrote about the Agile and Lean relationship. In gist, the picture drawn was similar to two concentric circles, where the inner circle represents a set of practices that are Agile and the outer ring represents the guiding philosophy that we know as Lean, in context of software development. It is time to refine that picture a bit and see how it morphs further. One of the most important concentrations of Lean is on the value stream from beginning to the end, or as it's called in business lingo, from concept to cash. Lean just doesn't talk about one process in the whole value stream and then stops. In the manufacturing world, Lean mandates consideration of the suppliers, vendors, and sellers. It looks at optimizing and reducing the waste from a product and its associated processes from the origin to its walk out the door. In the software world, this would translate to, for example, picking up an idea when it is still an idea (not a project yet), its evaluation, breakdown into project(s), getting them chartered and funded, team assigned, developed, rolled out, and installed for availalbility to business. A Lean practioner would want to look at how business value is being generated end-to-end and how the waste can be avoided in this entire thread. Agile, on the other hand, has concentrated only on the software development and the chain downstream, historically. While eliminating waste remains on the agenda of the Agilists, their sphere of influence is a project or a few. They also, typically, ignore the upstream steps. There may be complex reasons behind it but one obvious reason that I have observed is the unwillingness of Agilists, who are typically technical in nature, to meddle much with management. Project identification, chartering and funding is usually seen as a management activity that the Agilists have shied away from. For a Lean practioner, the boundary between technology and management doesn't really exists.

Future of Agile as a Competitive Strategy

2008-01-24T06:23:00.000-08:00

Michael Wah, Senior Consultant at Cutter Consortium, wrote an interesting article this month titled 'If Agile Were to Go Mainstream'. It mentions the advantages that Google has over Microsoft in time-to-market. He says, "Google is apparently practicing a more agile, iterative-style approach (sometimes quarterly) to releasing software, while Microsoft is more tied to the big-bang, multiyear cycle for its products." This is not a news anymore. One has only to be a Google user to be able to see that they release new tools many times a year and improve the existing almost as often. It's the next line that I found very interesting in which he muses on public perceiving Google as "agile and adaptive" and Microsoft as "heavy and slow".

Similarly, Netflix is raging its own battle with Blockbuster and Apple in the DVD rental space. or should I call it the movie rental space since it's soon to be a mainstream instant watch service too. A recent article (Freedom of Fast Iterations: How Netflix Designs a Winning Web Site) talks about how Netflix gets to try out new designs with real users very fast using iterative design approaches. Forecast The message in both these stories is that Agile development or Iterative development is actually being glorified like none ever before in history. The exception may be Lean, which has been talked about in media a lot. So the questions are:

What's the future of Agile with its foray into mainstream? - Are we likely to see an environment where every one will talk about it, understand it, but only a few will be able to implement it right?
Is Agile fast attaining the status of a competitive strategy? - Are we heading towards an environment where the end users will choose and companies will sell a product based on how it was built, much like Toyota.
What will be the future of Agile as a competitive strategy? - Is the mainstream adoption of Agile over-exposing it? How can the negative publicity by failed Agile adoptions be avoided?

The Road Ahead Here's what I think is going to happen. Agile will remain mystery to a large proportion of adopters. The reason I say so is because very few care to know the 'Why' of practices. Just adoption and implementation of practices doesn't mean that they retain the essence of Agile. As for becoming a competitive strategy, I think it will because it already has started to be. Let us analyze it from the perspective of users, competitors, clients, investors and the adopters themselves.

As a user I have more trust in a company like Google that releases better products more frequently because in cases there are bugs or deficiencies of functionality they won't stick around for long.
As a competitor if I haven't adopted Agile yet, I know that I am doomed because even if I start now it'll take me years to become Agile enterprise wide.
As a client of Google products I know that that I am always using the latest and the greatest that the company has to offer and it is highly unlikely that it is obsolete.
As Google/Netflix, in addition to having reaped the benefits of innovation, faster time to market with less waste and just enough I have potentially saved millions of dollars. This to the investors will be a sweet melody once Agile goes mainstream even on Wall Street.

As for the future, I think Agile is about to face some hard time. With very few people trained do it right, heavy potential demand and mandatory Agile implementations carried out by those untrained teams that are likely to create another thousands of untrained Agilists, the outlook looks grim. I have come across and discussed a few cases where huge projects are masquerading as Agile projects and will most likely be a nightmare soon. Given the small size of Agile community that has actually made Agile as successful as it is today, the battle they will likely fight with the skeptics will be bloody. Transition Plan Given the not so pretty outlook how can we better prepare for it? Couple of scenarios that come to mind are:

Start attending Agile conferences or join the nearest Agile community you can find.
It's never too late to start experimenting with Agile on small projects.
Get help from outside. Although small, the Agile community is largely independent consultants that are very knowledgeable and innovators. Needless to say that a lot of them are extremely good at what they do and that shouldn't be a surprise after you have a read a couple of their publications.
Lastly, if your company is serious about Agile, get help from consulting companies who have a lot of experience with Agile.

The transition and change to Agile, specially across an enterprise of thousands doesn't come about easy. It is not going to be smooth and there are some failures bound to happen. It's span and scale, however, can be minimized by utilizing a mix of approaches mentioned above. It may not just be enough to get a few of your people to attend conferences and embark of the change. Ideally, it should be mixed with some sort of external expertise.

Picture taken from: http://www.grandprix.com

Lean Vs. Agile OR Lean and Agile - A Relationship Defined

2008-01-16T18:25:00.000-08:00

Several conversations in context of Lean and Agile have revealed a few patterns that I would like to share. Some people talk about Lean and Agile as if they are the same things, some try to distinguish as if they are not, and some are simply caught between the two, not sure what is what. Another observation - a lot of folks in their conversations use Lean and Agile and almost come across unsure about what they exactly are. I have heard them all - agile way, agile manner, agile methods, agile practices, agile processes, agile framework, agile tools, and a few more.

What's the difference? Let's see if the two bullet items below start to draw a picture:

Lean Thinking and Agile Methodologies
Lean Principles and Agile Practices

In the software relam, Lean is a philosophy and Agile is a set of practices. In not so refined and all encompassing manner , the philosophy is to avoid the waste which can be implemented using some practices. That's the difference. Wait a Minute! Joe: Isn't Lean a manufacturing concept and Agile from software development? You can't compare the two. Jane: Well, haven't you heard of Lean Software Development? Joe: I have, but I have always had the doubt if two fit in together.

Unified Principle Different Practices/Tools It's a mistake to see manufacturing and software development as two different things in this context. They are one and the same, fundamentally, producing a working mechanism. The lean philosophy or thinking is implemented in manufacturing using Lean toolset, whereas in software it is implemented using Agile practices. The guiding principles still are the same:

Eliminate Waste
Center on the People
Flow Value from Demand
Optimize Across Organization

Lean in manufacturing have implemented their principles using some building blocks (tools and practices) like 5S (work place organization), Total Productive Maintenance, Visual Controls, Concurrent Engineering, Kanban, Work Cells, etc. The seven wastes of manufacturing that Toyota identified - Overproduction, Waiting, Transportation or Conveyance, Over or Incorrect Processing, Excess Inventory, Unnecessary Movement (Operator Motion), and Defects - are the guiding principles behind some of the Agile practices and their evolution. Agile community's adaptation of some of the practices/tools from Lean environment have given us Pair Programming, Continuous Integration, Test Driven Development, Small Releases, Coding Standards, Sustainable Pace, Collective Ownership, etc.

So, it shouldn't be a questions of Lean or Agile, or Lean Vs. Agile. They are neither competitors nor mutually exclusive, when it comes to software development.

Picture take from: http://chohmann.free.fr/lean.gif

Tangents, Details, and a Beaten Dead Horse - Throes of a Meeting

2008-01-10T19:00:00.000-08:00

Let me not even make an assumption that you have never been in one of those meetings where some of the participants botched it down. We all have been through those and, most likely, have been guilty of bungling meeting ourselves. That happens - yes, even the most experienced of us get carried away over-explaining the Aha ideas, or sharing war stories and anecdotes and get into details that are not so engrossing to others.

Until Jeff Patton demonstrated a polite way to rescue a hijacked meeting I stood a very high chance of being labelled 'Mr. Nuisance' for abruptly pointing out digression and demanding a move-on. Yes, I am surprised that no one has questioned my emotional intelligence on my face so far.

REMEDY

The panacea I learnt is to use placards. Prepare a set of 3 cards that read, SOLD, TANGENT, and TOO MUCH DETAIL written on one card each. Make sure they are accessible to each meeting participant - prepare multiple if required. And before a meeting ask your participants to raise and display the card to you if they think there's a need. This is a very polite and empowering manner to give feedback, real time. All my meetings have them now, although I haven't been shown one in a while. This, however, should be used with strict ground rules.

GROUND RULES

Participants should not play with cards during the meeting and will only reach out for them when a use is intended.
A card show will have to be honored and acted upon by the speaker.

Role Centric Vs. Process Centric

2007-12-25T03:23:00.000-08:00

A lot of projects, specially if they are Greenfield, require a Business Analyst to concentrate on the As-Is/To-Be world. Some people call it the Current Method and Proposed Method Analysis too. This is probably one of those workshops/session with the Business where, typically, the Analysts sweat the most. It is also the one that is difficult to start and sometime also the one where you never know until the end if you took the right approach. The reasons are many, with the biggest of them being the different views an Analyst can take to understand and model the process. You can either study what the different roles involved do (Role Centric) or you can study what the different processes in various departments (Process Centric) are in the current world. Usually, the As-Is has a very significant role in determining the To-Be world. This is what makes an Analyst nervous because if you start with the wrong approach, you risk ending up in a To-Be world that may not be the ideal solution to the problem. Now, a lot of times projects may not be greenfield - they can be conversion where an application is being converted from one technology to another. A lot of projects, in certain domains and specially large companies also include product swaps - replace a custom written application with a COTS product but customize and configure it to meet the needs. In these scenarios an application already exists. Example Imagine there's a bank that has an Internet presence where its customers can carry out their standard banking transactions online. This application was custom written in the late '90s where there were not many banking and payment technology solutions available out of the box. But now there are, and our bank wants to move on to this product because there are 100 other banks using it, amongst other reasons including better and robust technology, technical banking expertise that is not be maintained in-house, etc. As an Analyst you are task is now to roll out requirements for this new banking solution. The temptation in the above mentioned scenarios is to start going screen by screen in the current application, recording the existing functionality and writing requirements for the new one. Other than the fact that with experience this approach becomes less favorable, let me also introduce another mini-scenario. When this project was sold by the technical team to the business, it was pitched as an opportunity to throw away some existing functionality and introduce a slew of new e-services. Now, where do you start. Would you want to be Role Centric or Process Centric? Role Centric approach would be, at a higher level, be to identify the different roles that interact with the current systems, and their goals. e.g. New Customer > Wants to register or Existing Customer > Execute Electronics Funds Transfer (EFT). Process Centric approach would be to identify different areas of the business and the processes that can be done in the current application. e.g. Customer Service Center > Registration process or Core Banking > EFT process. So, which of these - Role Centric Vs. Process Centric is right? This is where the uncertainty creeps in and decision paralysis strikes you out. My answer - none of them is wrong. However, process centric is usually efficient to do. It avoids having to repeat almost similar processes for different roles. Roles can then be identified for each of those process steps and the exceptions can be recorded. If, on the other hand, we choose to go the Role Centric route, it is highly likely that for each role, similar processes with slight variations will induce repetitions. The role centric approach invariably leads to a workflow analysis. Same Stories Regardless of which approach you take, both of these As-Is and To-Be approaches result in stories that should not be very different. Some stories from the above examples will be:

As a New Customer I want to register online on the bank site.
As an Existing Customer I want to transfer funds electronically to external/internal accounts.

If you look closely, Role Centric and Process Centric approaches are really not that different at all. It baffles me anytime I see Analysts struggling to start or not feeling comfortable with the approach they have chosen.

The Chicken and Pig Story

2007-12-22T07:31:00.000-08:00

Previously, in posts, I have used terms like Pigs and Chicekn in context of daily stand-up meetings. The cartoon up there depicts the Chicken and Pig story and explains the terms Chicken and Pig very well. Picture take from: http://www.implementingscrum.com/blog/2006/09/11/the-classic-story-of-the-pig-and-chicken/

Conversation - A Dying Art

2007-12-18T18:30:00.000-08:00

Isn't it really? That's not to say that people are talking less. It's just that there is very little conversation in all that talk. Listening, which is an extremely important component of any conversation, is a painfully hard skill to find. It is not just me who feels that. Today someone asked me about my educational background. When I told her that I am an engineer, her first reaction was, "Really? See, I have a few nephews and nieces that are engineers, but it is hard to strike a conversation with them." I asked her the reason(s) and she said it is most likely because they don't listen much. Isn't lack of listening abilities very common in the industry, specially software development? The more experienced we get the more we get disillusioned that we know it all - been there, done that. This leads to a verbal exchange of ideas that isn't a conversation at all, many times. Conversations, however, are the bread and butter for Consultants and Business Analysts. If conversation is a dying art then they should be concerned. So, if you ask me for one skill that is at present very important for a BA to have, it'd have to be listening.

Information Radiators - Origin of the Term

2007-12-11T19:04:00.000-08:00

Last week in my post on Information Radiators , the description of the term made it sound like as if it was coined 'by' ThoughtWorks. This is not the case, as per Alistair Cockburn himself. I apologize for the confusion. The term was coined in 2000 or 2001 by Alistair Cockburn while he was visiting ThoughtWorks (while staring out at the walls from Martin Fowler's office, describing the idea of "convection currents of information flow" to Martin Fowler and Ward Cunningham), and subsequently written up by Alistair in his books and articles.

Information Radiators

2007-12-03T05:59:00.000-08:00

One of the tools and techniques, which I have seen, being used by many highly functional teams is Information Radiators.

We have all come across them in some form or fashion at work or in public places that we often visit. The term "information radiator" was termed in Thoughtworks (source: http://alistair.cockburn.us/index.php/Category:Information_radiator) and refers to a publicly posted display that is large so that it is easy to see. When I first heard of the term I didn't get to see an example. That left me with no picture of how to implement information radiators, if I had to. Now, I have lots and here are some pictures that may give you some idea of the nature and size of information radiators. In the pictures on the right, there's different kinds of them:

Large card walls or card tables that grab people's attention as they walk in into the workspace/team space.
Blown-up progress charts, etc. that the team members can look at from far corners of the work-space.
Flashing light that illuminates any time there's a failed build is yet another kind of information radiator. You can see one sitting on the top left corner, on a cubicle wall, in one of the pictures.

A lot of industries outside of software development have used a variety of these radiators in the past, very effectively, e.g. in manufacturing environments it is not unusual to see the shift production numbers displayed in real time, or hear sirens indicating malfunctioning equipment. These mechanisms still exist in this day and age because they are very effective. As people engaged in high-tech, we should innovate and try to use the same principles in our industry too. I am interested in getting to know any other kinds of information radiators that you have either used or come across in the past.

Understand the 'Why'

2007-11-12T22:20:00.000-08:00

With any new useful knowledge that we encounter a change in behavior usually follows, if we decide that the body of knowledge is useful or will lead to better productivity. We then try to follow the steps/methods that we were trained in, often seeking feedback from the people who are considered experts. It is not unusual for the trainers to have doubts on whether the best practices and methodologies that they have shared with the participants will survive after they move out of the teams. Is is also not unusual for managers to worry about the longevity of the lessons learned by the team and their inculcation in day-to-day work, once the trainers are gone: The other side of the story is the execution of the practice. For trainers it's a nightmare when (s)he starts getting questions like:

Do we always have to do this?
Can we do without these steps in the process?

Even worst is the scenario where you get to hear:

This will never work here.
It looks good on paper, but in practice no one will follow it.

The result, usually, is not pretty - it's an ache for both trainers and managers; frustration for consultants, and a fear of failure and sunk cost for the managers. Two lessons that I have learned in the past few weeks have been very valuable for me to avoid these problems. 1. Always, reinforce the 'Why' - There are two big advantages of re-enforcing the 'why'. First, if practitioners know the reason they have to do a certain thing, they'll always remember to do it. Second, if the practitioners understand the value that we are aiming for, there are good chances that they will experiment with other options, and there are fair chances that they'll innovate. 2. Use Socratic method - Consultants have it in their blood to solve problems, cut through the confusion and solve problems. This, however, may not be the best style if it is carried out for long. A switch of strategy is essential to learning, where the consultant should start asking questions in order to answer questions. This not only increases the confidence of the team members once they find themselves solving their own problems, the quality of information/idea exchange just shoots through the roof because the level of questions that end up being thrown to consultants really deserve the top dollars they are being paid. Understanding the 'Why' had always been my focus, but I never was as big in passing it along as I now am. This came out of a meeting that I had with a client manager who wanted to ensure that the system remains greased after we had left.

Open Space Configuration - Possibilities of Communication

2007-10-02T16:34:00.000-07:00

Are you one of those people who dream of an office space or are already in it at your software development shop? If so - you won't like what you are about to read, but I want you to continue reading. A Big Frontier - But Rewards are High There's no doubt that offices and cubicles create silos and inhibit communication. Every time I hear something like, "I/we have an open door policy" or "But, we do communicate", a shiver of despair shoots through me and it usually ends with a sigh. Really? No, it's not that bad, yet. But I'll be there if I continue seeing the ugly walls and partitions for a few more years. Sometimes, I wonder how this displeasing concept of cubicles caught on the frenzy in the first place. Beyond just the questionable aesthetics, offices and cubicles are a waste of space and a barrier to communication. I think it is the best way to stifle creativity and productivity. Here are some of the things that I have observed and heard from other people:

It reduces face to face communication.
Impromptu meetings are almost non-existent. As a result, formal meetings go up in number.
Face to face communication goes down drastically. I have been in both cubicle and office space in the past and just the sheer number of emails that I get is a reflection of how bad the communication gets. Things that could have been discussed in end up in emails.
It is hard to look around for people. You can't see if people are on their desk or not.
It usually leaves very little space for collaboration. Meetings rooms become a luxury and their availability a matter of luck.

The challenges posed are monumental not only in the waste they create, but also in the resistance to change that it faces. The alternative is Open Space Configuration, which in all respects is not only better but also very configurable. I will explain a little later what I mean by configurable, after listing a few benefits of an open space configuration:

There's more visibility into who's around and in the team in general.
Team members communicate more. The need for formal meetings goes down.
Easier accessibility to teammates.
There are better chances of hearing conversations that one should participate in but would have missed otherwise.
It provides more room for daily stand-up meetings.
It becomes harder to slack at work. Procrastinators benefit the most out of open space configuration.
There's less waste of movement.
All this results in a whole lot more collaboration.

Another big benefit is that the open space configuration is flexible, which allows the team members to change the layout more frequently, based upon the changing structure of the team. This is what I meant by 'configurable'. If members move from one team to another within a projects, an open space layout is conducive to adjustments.

Some Possibilities in Open Space

The first picture that flashes for most people with Open Space Configuration is a big room with a large conference table with some chairs and that's it. Emotions run high and are all over the map:

I feel demoted and less important.
I'll be envious of people who have cubes and offices.
Getting an office was a motivation for me. What would it be now?
It'll be chaotic. I'll feel frazzled and won't be able to deal with the crazy environment.
I am always being watched.
How will I make private phone calls?
It'll be a pig sty.
I am going to find a job where they have offices and cubes.

Here's how I, personally, felt when I moved from an office to an open space:

Equal - My managers and 'super' bosses had way bigger offices with beautiful window views and all I had was 4 windowless walls and a door with a peek hole. In open space the team shares the same window views. A sense of equality creeps up.
Privileged - So much news that otherwise would have died out behind office walls or in email threads get communicated in open space. I get pulled into discussions that are otherwise held behind office walls. Being privy to such discussions is a very special feeling.
Liberated - There's really nothing much to maintain in an open space. All the junk that otherwise piles up in cubes and offices just doesn't survive in open spaces. Open spaces are socially maintained spaces. If you don't throw your junk away, someone else will.
Learned - There's so many new skills I learn in an open space environment from observing other people and how they work that I wish I didn't waste all these years sitting in cubes and offices. A good example is the usage of Post-it Note stationery. I grew up not knowing what it was and got introduced to it when I was about 22. For many years after that I just used it to take quick notes. In the last 2-3 years, however, by observing other people use them in different ways, I have learned to use Post-it Notes for so many other things including information gathering and organization.

Somehow, open space conjures up an image of one large table in a room with hundreds of people sitting around it staring at each other. Like any other concept that can be misunderstood or exaggerated, this one has got its share of bad publicity too. An open space can be configured in so many different ways that to make an unfavorable judgment about it without trying is outright insensible and imprudent. Just for reference, the pictures on the right are some of the different layouts that I have worked in and have found to be very effective for communication, team building, creativity, and my overall professional well being. Some more pictures:

Break the Mold

For those of you who are still skeptics, I would highly recommend to read Organization and Architecture of Innovation - Managing the Flow of Technology, authored by Thomas J. Allen and Gunther W. Henn. It's link is available in my recommended list of book on the right side. A few of the things that these authors talk about are just phenomenal. For example, we all recognize the importance of communication but don't quite associate it's importance with the end goal. Thomas and Gunther talk about Communication for Coordination, Communication for Information, and Communication for Inspiration. While most of us are aware of the importance of communication for coordination and information, we seldom see its contribution for inspiration to be creative. Some of the research cited in the book is also very telling, e.g. the probability of communication goes down drastically with the increase in physical distance between individuals. Another good research is that the probability of telephonic or IM conversation is strongly correlated to the probability of seeing that person face to face. This means that chances of an individual picking up a phone to talk to an individual that (s)he doesn't see in person are almost as little. Visual Communication also has been cited as very important - seeing a person one can be reminded of what (s)he was planning to talk to this person to and, most importantly, to get visual feedback. Often in the industry people solve abstract and complex problems that require visual communication.

The rewards and returns for going open space are so high that I now understand why a lot of labs, research & development centers, and even custom software development companies invest time, energy, and money into designing office spaces that we just don't give any thought beyond uttering "Cool!".

A few days ago, my colleagues directed me to two resources online that I would recommend reading to anyone considering going open. Death of Cubicle; the Open Office Experiment was an experience report from Agile 2007 Conference, and How does Radical Collocation Help a Team Succeed is a 2000 ACM Conference with lots of research data and quantitative measurements.

If you are aware of any other work environment that has gone open recently, I would be very interested in getting your opinion and feedback on how it went, benefits, etc.

What do Managers do in Self-Directed Teams?

2007-09-27T06:36:00.000-07:00

There's a lot of buzz about Self-Directed Teams these days. The concept is very revolutionary and self-evidently beneficial as long as you are not the manager of the team. Think about it, suddenly a team is self-directed - everybody knows what they are supposed to work upon, they pick their work, solve their own problems, meet every morning and update the team of the contributions to it, etc. The team members are very conscious about the business value they are delivering and have managed to get the communication channels set up within the team and built bridges across to the business. Utopia, isn't it? Well, for some it might not be, or so it seems. Put yourself in the shoes of the person who was until a few weeks back was managing this team and ensured that all these things happened. But now, these have started to happen and it is all being managed by everybody. So, the big question this person has is, "What do managers do in self-directed teams?"

Now that the team members are doing what I did day-to-day, what's my role?

Do we need Managers anymore? If this concept of self-directed team is a reality at all (some actually doubt the feasibility of it), then what might possibly be out there that they can't do on their own and would need a manager for? If I am a manager for a team that is on the path of becoming self-directed, how can I save my job? What should I as a manager be doing next that might be valuable?

Some of fronts on which I have seen self-directed teams needing help are:

Leadership - While the teams is busy managing their own internal affairs, there's some shepherding still required to lead the team in the right direction, which is aligned with the vision and mission of the company. There's a good blog-post I found that very aptly describes the differences between sheep herding and shepherding.
Removal of Barriers - Barrier Busters: As much as it seems to be non-issue, it is. Teams that are solving cutting edge problem and busy developing solutions for tomorrow, are surprisingly also very poor at removing barriers on their own. It is not because they don't want to, but more often than not it is because their barriers are non-typical. They can be anything from regulatory, trade, and market barriers to politics, bureaucracy, etc. Teams involved in technology generation are usually not very interested in speding their time in these kind of issues.
Facilitation and Co-ordination
Development of Staff - Training and Mentoring: Often overlooked and seldom undetook, training is very important. I'd recommend everyone to read The Cycle of Leadership by Noel M. Tichy. Read more about the book at: http://www.noeltichy.com/cycle.html
Driving Innovation - Innovation today is what strategy used to be until a few years back. You need to be on the bandwagon of innovation. Needless to say, it requires a certain amout of experience and familiarity with the business, a deep understanding of the tools of the trade, courage, and bandwidth of time and resources.
Sharing Lessons Learned with rest of the Organization - Amongst large companies that are out there the difference between really successful and barely sustaining ones is the difference between their middle managers. In companies where middle managers are messengers of lessons learned and different successfully implemented ideas there is a certain robustness, pride, and confidence. GE is a good example of this model. It's a big job and requires tireless efforts on behalf of the middle management, but seldom picked up by middle managers.
Continuous Improvement - There are very few teams that like change. Once they have stablized they, infact, resist change. And then there are some changes that are not very pleasant to think of, at least on the onset. e.g. a change to move the team from the wasteful office cubicle layout to open space configuration. A team needs a manager to make such decisions and also to identify other things that can be improved.
Process Czar - Let's not forget that no matter how self-directed a team is, it'll start to cut corners. It is a manager's job to to make sure that the processes that the team has chosen are being followed by everyone and if not, then to figure out the reason(s) and modify the operating guidelines.

I would also like to encourage the readers to share their experiences, observations and opinions on the role of middle management in their organizations. Please feel free to comment on this post.

Image taken from: http://www.toothpastefordinner.com/070806/manager-set-list.gif

Mingle is Out!

2007-09-24T16:04:00.000-07:00

A few month ago I wrote about the importance of a card wall in agile software development projects and the value it brings to iteration and project management. It can be found at: http://bizvalu.blogspot.com/2007/03/card-wall-its-not-reversion.html . There were some comments around the wall being impractical or not suitable for distributed teams or if the team is too large. In my discussions with a project manager recently, it again came up and he expressed his skepticism of card wall specially if managers are working remote or travel frequently.

Thoughtworks (http://www.thoughtworks.com), which is a leader in agile software development, specially distributed projects has released a project management tool called Mingle that is an electronic version of the card wall and is configurable to mimic any variation of a physical card wall layout.

I would highly encourage you to take a look at the tool. You can sign-up for a trial here and see small and quick videos of its features here. Apart from being able to generate your own tags, that serve as meta-data for the cards, and linking code to requiremetns, Mingle generates some of most effective metrics that I have ever seen.

What's your velocity?

2007-09-06T19:00:00.000-07:00

For the past couple of years I have been working in teams that measure their productivity and throughput using a term called "Velocity". For a team that is engaged in software development and delivery every story is estimated at certain points worth of effort that is required to complete the story. The sum total of points for an iteration's completed stories is the team's velocity.

It's all about Development

The velocity of a team is its development velocity. That means it only measures the throughput and productivity of the development effort. There are no measures of these parameters for the QA and BA teams. Some of the practical constraints are that these groups are not as insulated as the development group and neither as ideally served. By that I mean that the Development group in an iteration is bound by the time of two weeks to finish their effort and are provided the material (stories) to develop from. So it makes it easier to measure their velocity and the number reflects the nature of a very controlled environment. Business Analysts on the other hand don't have this controlled environment. They have to interact with users and business outside their immediate sphere of influence and control. So the Business Analysts are not bound by iteration length for analysis. They can take anywhere from 1-3 weeks to analyze a story. And it is true for the QA groups as well. So, the problem is that Business Analysts and QAs have no idea of their velocity.

Is that a problem. My answer would be, "it depends". As long as the development team has enough work to do with just the right inventory of stories on which they can stretch if they finish their work early, who cares. On the other hand, there are some who'd want to know their throughput. So, there has to be an indicator for Business Analysts as well. Estimating the Unknown The problem, however, is the concept itself. Velocity is computed from the estimates that are reflected by the developers based on the story details. In case of the Business Analysts, they don't have anything to estimate. They are in the business of creating something that can be estimated. So, the big question is, "How can the Business Analysts estimate their analysis"? The second question is, "Should they even do it?".

Standup Smells - Chicken plays Volleyball

2007-08-29T15:31:00.001-07:00

In one of the previous posts ( http://bizvalu.blogspot.com/2007/03/stand-up-meetings-progress-of-team-vs.html ) I talked about Stand-up meetings and referred to a good paper written by a ThoughtWorker on it. I also discussed a few things I like about it and how they improve the quality of work I do. This post can be found here. Recently, I started observing a few smells in stand-ups that I haven't seen before. Yes, please don't tell me that 'observing a smell' is absurd. I know I know. Anyhow, two trends in specific:

I am a Chicken: A participant asks a lot of questions, in a manner that portrays him as a leader of some sort. But when it was his/her turn to contribute to the stand-up (s)he passed saying, "I am just a Chicken". So, you should not switch between a Chicken and a Pig in the same standup. Either you are a Chicken throughout a meeting or a Pig throughout a meeting.
Volleyball: In a stand-up the participants don't have to necessarily move in order. In other words, the group doesn't necessarily have to talk in a clockwise or counter clock wise direction. It can be random, which actually increases the attention level in the group because no participant know when (s)he can be thrown the token. However, this token throw is misused a lot, where two people keep throwing the token between each other getting in the question-answer mode. This is a smell. First, it clearly indicates that the issue being discussed is getting too much into details and second, it's just not about two people.

I am not saying that people should not seek clarification; they definitely should. Afterall, what's the point of the meeting if what is said is not understood by any. But a back and forth or a volley of questions is indicative of a broken stand-up. Also, a chicken asking too many questions makes it a one person show, which is not it is intended to be.

Road To Success

2007-08-29T15:29:00.000-07:00

A lot of folks in corporate world remember the late nineties and early years of this decade as 'boom and bust'. Those tales of riches and the plunder in corporate boardrooms that followed have become folklore lately. And then there are subtle variations of these in other places where the CXO are either chucked out for lack of performance of they just walk out because the change they initiated is not going to happen for another 2 years or so. Result - an impatient investor, a board that will most likely behave like a headless chicken and and a looming uncertainty that instills fears and haphazard decisions. The habit of instant sense gratification has now perched itself high up, even in the board rooms and on Wall Street. Everyone desires success and demands immediate results. Or, at least that's how it is likely to be in North America. The Big Corporate Disconnect Having gained most of my experience as a consultant in this kind of environment, where overnight turnarounds, complete overhauls, reorganizations, etc. have become the staple strategies for results, it came across as no surprise to me that the leadership started showing signs of ruthlessness, shallow understanding of their problems and business models, and far too little commitment to solving problems from the bottoms up. The top down approach of command and control is still being used as a means to communicate vision, rather than encouraging participation of the employees to set the vision of where they want to take the company. The result is a big disconnect between the definition of success as the senior management usually understands it and how the rank and file of their companies understands it. A side effect of that is rationed communication when it comes to morale boosting of the employees, which starts to dilute the communication and inturn the trust and faith that the CXO has invested in him/her. At the end of the day every CXO utter very similar things - investor, walls street, and earnings. No one either cares or has the confidence and courage to talk about technology, training, infrastructure, IP, quality of people, etc. The reason probably is the slow turn around of the latter, whereas the numbers (profits, earnings, etc.) can change month to month significantly. Long story short, CXO exits start when there's a bad run of numbers and since these folks never invested time and energy in studying and exploring other fundamentals, dollars is all they have got on their report cards. I think, that it is not only foolish but also misleading. The lack of willingness, passion, and experience in concentration, investment, and tracking the fundamental of any business like people, training, etc. is not only a disservice to self but also a breach of trust that the workforce indirectly invests in their leaders. Paradigm of Vision and Leadership So, what's new about it and so alarming that I am investing time to write about it? Recently, I met a CIO and started to work for him and had a chance to listen to his plans. In the process, I am also getting some insight into the decisions he has made, and most importantly the thought behind those decision. His thought was along the lines of getting ready to be successful and then embarking on the mission, and monitoring that progress as often as possible. He defined it as a 'Road to Success' and wants to watch mile markers. The mindset in itself is very radical, for an executive at his level, where more often than not people lose sight of the appropriate details, and don't want to be bothered by what's going on on a daily basis. They have people and they expect those people to just somehow magically produce results for them. The analogy of road to success is very refreshing to come across in the business today. This is going back to the basics of management, where you determine your goals and target, evaluate what it'll take to get there, the resources you have, and the path you want to take, with the courage to solicit help from outside if desired and then having the energy and appetite to follow it through and absorb the shocks in between. It is fun and rewarding to work for people who understand that getting on to the road to success is as much of a cause to celebrate as it is getting there. I am almost tempted to use, "Well begun is half done". Looking back at a lot of work that I have done, it isn't very difficult to pick out experiences where we, as a team, knew that we were headed in the wrong direction, but helplessly watched us go down that path because we didn't know what the road to success was. We knew that it was not the one that we were following, but lacked the courage to stop, a determination to explore, and the leadership to raise this issue to the people higher up. Most importantly, on a monthly basis we got to know from our managers that the VPs, and EVPs just don't care how we do it, we just have to do it. 'Road to Success' is a paradigm that not only instills confidence in the team but also gives purpose to projects and extracts the best out of people. They know that they are on the right path, the leadership knows that they are on the right path, and in the end the board, the analysts, Wall Street, and investors know that the results will follow. Image taken from: http://alum.mit.edu/ne/whatmatters/200501/images/success.jpg

Round over Rectangle

2007-08-25T05:22:00.000-07:00

Usually, a lot us sit on tables when we work unless some of us are lucky enough to be working in bed or sanded on beach. Another important part of a daily work routine is meetings, which are often carried out in environments that have lots of tables and chairs. Constraints of Space Recently I observed that almost all of the meeting tables are either rectangular or square in shape. Round is not a shape that's very popular in corporate environments, unless it's in the cafeteria or kitchen. My very educated guess is that it is due to space constraints; architectural layouts of most buildings do not allow for massive round tables to be accomodated. It's just not an optimal utilization of space. Or so one would think unless (s)he has an experience I recently had. We were all, seven of to be precise, in a meetings on a rectangular table where one of the participants had a lot to share and discuss and comment upon. But the layout of the table and how the participants were sitting on it made it extremely difficult for the speaker to be able to make eye contact or even look at the person sitting to his immediate left or the right until he turned the chair a little bit to the side that made most sense, facing a little towards the person sitting at the head of the table, which positioned his back towards me. This not only took me out from his view but also cut down his decibles for me. Reaction and result; frustration and loss of attention and focus. I would, actually, have been better of being on a phone meeting because the voice at least would have been clearer. The Second City I would not have otherwise written about this seemingly immaterial topic, but an event made me change my mind. Just yesterday I spent 6 hours with a group called the Second City (http://www.secondcity.com/) that is basically a theatrical group which has launched such brilliant careers as John Belushi and Mike Myers. My interaction was with their training and communications group that teaches improvization, acting, and other other skills. During the workshop it became quite clear that the business world today is facing a major challenge that the Second City folks are being paid top dollars for. Corporate North America wants its work force to get better at communication and bring some quality to it. And we as participants of this workforce are ignorant of our shortcoming in communication and people skills. Back to the round table Having had the experience that I had at Second City, first and formost I would recommend it to every consultant. But one of the points that I took home was a firm conviction that the design of furniture and facilities has a major role to play in the success of people and companies. If it hasn't affected you yet, it will start to in the months and years to come ahead. Rectangular tables have now become not only an eyesore to me but also a big no-no. They project an image of unproductive, broadcast (one way conversation) kind of a meeting environment that glorifies hierarchy. Round tables, on the other hand, radiate collaboration, high-energy and flatness in the group, which is mantra for success in any modern business. Image taken from: http://www.engage-em.org.uk/index.php?tab=index

Enablement or Delivery - What's my responsibility?

2007-08-16T07:29:00.000-07:00

For as long as I know, consultants have been thriving on the demand for improving processes, helping businesses transform, design and deliver solutions, and make decisions. They all seem to be types of engagements where you provide a service, add value, get paid for it and walk away, often like a star. But what you leave behind is a very temporal product that will again require your or some other consultant's services to make changes to it. One of the other types of engagements that I have been associated with lately also is 'enablement', where it is my responsibility to ensure that the client understands what I do and how I do it, and so it is for my other team members who represent Development, QA, Project Management, etc. The differences between the two is huge. From the fishing world analogy, it's the difference between catching a fish on client's behalf and teaching the client how to fish. The end product in both cases is the fish but it's the experience and the skills attained that make the difference. This is how I differentiate between 'delivery' and 'enablement' projects.

This differences, however, start to blur when the teams are co-sourced. By 'co-sourced' I mean that there is client member representation in almost all of the activities like analysis, development, testing, etc. It may very well be a delivery project but the team structure and the dynamics start to make it look like an enablement project. This illusion gets stronger as the proportion of client representation in the team start to grow.

With co-sourced teams one of the challenges is to be able to influence the practices and techniques of other team members so as to make the team productive and derive high productivity out of the group, something that I am used to and all of us strive for. A reaction to that realization is to start sharing best practices and having lunch and learns where a lot of knowledge exchange happens. I learn a bit about the client and their systems and they learn a little bit from me. Good results start to follow, more often than not. And then we (both client and I) get hooked on to this style of work where apart from delivery we start carving time out for knowledge exchange.

Suddenly, the questions start to pop up.

What am I here for?
What am I getting paid for - delivery or enablement?
What will I be evaluated upon?

Answering any of these questions will no doubt sway any consultant in the direction that avoids enablement, when (s)he is on a delivery project. These used to be a hard ones to answer until I started asking myself a different question.

Why am I here?

The answer to this question is very straightforward for a consultant. I am at any client's to generate some value. And value is generated not by one of two members of a team but by the whole team. If I think that some members of the team are not generating value for whatever reason, I get into the enablement mode to ensure that they are getting all the help and support in order to become valuable members of that team. That in the end will help me generate the value that is being sought.

Imperative of Delegation

2007-08-13T11:21:00.000-07:00

Challenges, both people and technology, are an integral part of any project. It is said that if there are none, then you should reconsider your involvement in the endeavor. Every project struggles with staffing at some point in time. There's no set formula that spits out the team composition or size based on the problem. Teams usually start with a certain number of people, based on past experience, and then either add or reduce the size as a project progresses. Then, there are other things like commitment; the percent of their daily time are people committed to on a project. These factors in combination of others help estimate the team size to a certain extent. Delegation Maturity of Team Usually, people talk about the maturity of team when you discuss the team sizing with them. One factor that I have never heard being considered is how well the team members delegate. Has anyone of you asked yourself or been asked this question? Did anyone ever come to you and said, "What's your assessment of the delegation skills in this team"? I have never been asked, but I have asked this to others a few times. Decisions - Too Important or Too Dangerous So, why is this such a big deal? Well consider this situation. A team has a product manager who makes all the decisions on the priorities of the functionality to be developed. But, that product manager is gone for two days. Who has that decision making authority been delegated to on the team in his/her absence? Who sets the direction of the team. Probably nobody, because that's just too important a decision for anyone or everyone to make. Even if it is not, who would want to make such decisions? These situations are seldom considered to start with on project teams. And this exists on all fronts, product management, project management, analysis, development, quality assurance, design, etc. People don't want to delegate and the delegates are too afraid to call the shots. Importance in Agile Environments In Agile environments, where teams move ahead and track activities every day, this is a big bottleneck. This is what makes the teams dysfunctional and impairs productivity. And the more we delay putting a delegation structure in place the more fearful the environment starts to get. Decisions start to take longer, frustrations start to build up, and eventually analysis starts to suffer because analysts don't put in that much effort, hiding behind the excuse that there's no clear vision and we may end up dropping this functionality, so why put in too much effort into it right now.

No matter what methodology is adopted on a project, people have to be empowered to make decisions and should feel comfortable delegating this responsibility to other team members in their absence.

Image is taken from http://www.lindamoran.net

Obsolescense of a BA?

2007-08-06T08:13:00.000-07:00

For a lot many years we have now been witnessing that there are jobs that just go away. They are either obsolete or have grown so much in role responsibility that many new jobs have spun out of the original. I mean, who around us sees a milkman anymore and we all know what ever happened to the 'webmaster' of the 90's. Just a few days ago, John Berry, a Senior Consultant from Cutter Consortium talked about The Vanishing IT Organization in one of his articles. He talks about the IT organization ceasing to operate and exist as a clearly defined structure with its own office door. That made me think - when will the job of a BA cease to exit? How long do the BAs have before they should start planning their transition into some thing else where they might be useful? I encourage you to give this a thought and post your opinions on it. Image is from http://www-lu.hive.no/plansjer/engelsk/

From Stories to Scenarios - A necessary Step Back

2007-07-28T11:23:00.000-07:00

The mindset, when it comes to software development, implementation, and rollout has changed a lot in the last few years. The early years were all about planning, designing, replanning and redesigning, developing, implementing and rollout. This age is all about doing precisely the same things as above, but in much smaller and frequent intervals. That's the difference between Waterfall and Agile sofware development mindset. Agility, however, demands a change in the size of each individual problem that is to be solved. In other words, problem is broken down into smaller chunks of work that are then tackled in a fixed but small interval of time, called iterations. So, instead of tackling the huge problem, we now deal with features that are right sized for an iteration, which can be a week, two week, or three weeks long - called "stories". Stories Stories became the way to implement functionality in Agile environments. It still is and probably will continue to be the way for another few years until something new and better come across. This is because it is manageable, concise, and yet valuable. However, in a large problem space, the identification of stories still remains an art. There is no science behind story identification. And, as is true with any art, only a few are masters at it. For the rest, it's still a nightmare when someone asks, "Are there any stories missing?", or, "Have you been able to identify all the stories?", or worse yet, "Based on the stories that you have identified, how long do you think it'll take us to build a fully functional software to market?". Questions like these have forced the agile practioners (analysts) to reconsider the way they view the problem space. While they realize that stories are the way to build sofware, one piece at a time, it is probably not the right level of granularity to begin with. That ought to be the scenarios. Scenarios We should not jump straight into breaking the big problem into stories directly. There's an intermediate step, called the scenarios. What all would an ideal and super user of the software would want to do, in his/her typical day? The answer to that, usually, is a collection of scenarios. So, if the problem space is to build a end-to-end front-end equipment leasing system, a scenario in there could be: "User generates and prints lease documents". "User converts lease documents to different industry standard formats".

Benefits

Scenarios are proving out to be a necessity as the complexity and scope of the solution keeps growing to handle the 21st century global businesses. It ensures that the functionality needed in the solution doesn't remain hidden or unidentified. Stories can then be stem out of these scenarios. The other way round, stories can always be traced back to the scenarios. Overall, there's a better management of stories; missing ones can be identified and added soon, and the duplicates can be identified and eliminated as easily. There's yet another soft benefit to it. The teams can be divided to work on scenarios rather than disparate and unrelated pieces of functionality. For the product owners it becomes easier to see the big picture and priorotize functionality. Scenarios also make the release features easy to decide. So, as an example, with scenarios identified the product owners can decide that as part of release 1 the users would be able to generate and print but won't be able to convert documents into different formats like PDF, etc.

Collaboration Unleashed - Cardmeeting, Planning Poker, and Skype

2007-07-27T07:20:00.000-07:00

Collaboration has never been as important as it is now in the day and age of distributed projects. There is an ever increasing need for tools that simulate physical working environments with as much fidelity as possible. Simplicity is yet another attribute that is highly desired. No matter how innovative a tool is, if it's not simple to understand and easy to use, it's chances of a wide user base and retention go down drastically. In the last few months I have been introduced to tools and techniques that, I think, are unique in their simplicity and ease of use. Card Meeting As teams working in agile environments, one of the practices that is followed very religiously and by all members of the team is Retrospectives. The practice is self-explanatory - in short, it's a look back at the last iteration of work and an analysis of what went well, what didn't go so well, and what we can do to improve the situation. This is, typically, done in large meeting rooms with lots of wall space to stick up index card and stickies. As expected, it is a heavily communication oriented process that involves a lot of visual elements. Also, as expected, there are always team members that are working remote and are not physically present in the room. It has been my experience that for such people the effectiveness of a retrospective go down significantly for very many reasons. Some of them are:

Often, people in the room forget to take the opinion of folks on the phone,
Not being physically present in the room takes away the advantage of having a big picture in front of you, and
If there are changes being made to the index cards on the wall, it is hard to catch the subtle differences between the original and the new text.

Card Meeting (www.cardmeeting.com), it seems is a solution to the problem. It is a very powerful, yet simple to use, online tool for recreating a card wall that we typically use for retrospectives. Very much like with paper cards, card meeting presents its participants with the freedome to create their own multi-color cards on which all of them write and vote. Some of the benefits are:

No cards decks are required
No wall space, except for projector screen is required
Remote participants, who usually don't see physical card walls, can see all the cards which enhances their experience and contribution

Skype (Groups) Another problem that I have faced in the past on large teams is daily communication. The communication that I am talking about is the chatter that we all are almost always interested in being on top of. Email in the past has been used for it but has proven to be in-effective. One of the team members on my last project came up with the idea to create groups of users on Skype. On that project there were 3-4 different groups, Business Analysts, Developers Team-A, Developers Team-B, etc. This provides users the capability to broadcast messages that aren't too important for an email and are very temporal. It also prevents the rest of the team from being disturbed by what they consider to be noise for them. Planning Poker Although I have, officially, never been a part of estimation process, I have sat through the sessions and have helped the process by giving whatever information was sought from me. One of the observations I made was that often the estimates were either revised by the estimator because they didn't have the full and clear picture of the functionality the first time or because they got influenced by the other estimators in the room. The former happens a lot when the estimators are working remote and the latter when the estimators are all in one room and can see each other. Planning Poker (http://www.planningpoker.com/) is an online estimation tool on which you can upload a list of stories using an Excel sheet that are then presented to its participants one at a time. The participants, which usually are also on a conference call discuss each story and post their estimates that are not revealed to the group until the last participant has voted. At the time, all the votes are revealed. This can be any number of times until the group has reached a consensus. Summary In the recent few months, each of these tools; Card Meeting, Planning Poker, and Skype Groups have proven very effective for me on distributed projects both individually and collectively. They have enabled teams to work more effectively and efficiently and most of all, I have seen little or no resistance to their acceptance.

From Necessity to Nefertiti

2007-07-07T11:36:00.000-07:00

One of the most important aspects of any project, especially one involving a computer software / system is defining a set of accurate requirements. But many a times people end up either with too many requirements or too little. Sometimes you get requirements that seem necessary at first only to end up as superfluous or non-necessary for the scope of the project. There is this constant fear in the minds of the Business Analyst and Project Manager that somehow, somewhere, sometime along the due diligence and the long drawn out process of requirements elicitation, they have overlooked or completely missed a few critical requirements or what they say “must haves” and instead have included or focused on the ones that would have been the “nice to haves”. The result of “missed” requirements could potentially be catastrophic. If discovered way down during the development life cycle, these missed must haves can be quite costly in terms of time and labor to be added to the scope of the project. Similarly the erroneously included nice to haves can drag the project schedule beyond the already tight timelines and deadlines.

So the question is, how does a Business Analyst efficiently and effectively determine the absolutely necessary set of valid, complete and accurate requirements? And more importantly what do we refer to such a set of requirements? Over the years, I have come to use the term “beautiful” to such requirements. Yes, beautiful. Well that’s what everyone involved in the project is looking for isn’t it? Nobody wants “all” the requirements, nobody wants “valid” requirements, nobody wants “complete” requirements, and nobody wants “minimum” requirements. Everybody wants “beautiful” requirements.

The task to compile a list of “beautiful” or “wonderful” requirements can be gargantuan. There is no universal way. There is no magic pill. There is no silver bullet. Each complex project requires its own ministration. The BA must wear multiple hats and take on different responsibilities from being the business analyst to being the project manager to the user interface specialist to the developers’ liaison to project champion to subject matter expert to cheerleader to cattle herder to everybody’s friend and simultaneously their worst nightmare. All the standard concepts and techniques of requirements elicitation and requirements refining will only leave you with a set of necessary requirements. That is Science. Converting them into Beautiful requirement is an Art. Especially when you are dealing with a multimillion dollar project spanning twenty something departments and affecting five hundred something stakeholders with hundreds of teams working on something or the other affecting your project and under aggressive time lines.

Is there a Ferrari waiting for me on this speedway of Requirements Analysis to take me from the Essential to the Beautiful requirements? Maybe. But the clock’s ticking. And I better get going.

Signature of Trust

2007-06-06T20:18:00.000-07:00

One of the first few steps that a BA or the PM does on the project is to get a process in place, which shall be followed by the team (s)he is a part of. As part of the process it is important to identify the meetings that would be a part of it. Usually, team members that are required to be part of those meetings are identfied up front so that these people understand their importance and where they fall in the critical path of achieving the business value. Recently, I was reviewing such a process flow with a client team where I started observing a pattern. Some of the client representatives started to point out that I was missing their role reprsentation in some of the meetings. It was not a mistake. I had deliberately left them out of those meeting out of respect for their time and considering the stretch they were already in. It came as a little surprise to me that this didn't deter these people to point out their ommission from some other meeting. At the end of the it all, I observed that almost every one is involved in almost every meeting, which defeated the purpose of the exercise in the first place and also raised concerns about how this will eventually end up playing out. This prompted me to ponder on why they want to be part of these meeting despite their already busy schedule. From some of the questions that I raised to understand the rationale behind client's demand to be present in every meeting, I got the hint that they didn't belive in our abilities or were not comfortable enough with me making the decisions that they rather make. It is a matter of Trust. No doubts about it. It was quite clear that there was a lack of faith that decisions can be made by outsiders without the presence of client. My process right now lacks the signature of trust that I have utilized in the past to save the client a lot of pain and effort and anguish that is typically a part and parcel of a lot of meetings. I have come to belive that as this trust increases people feel more comfortable distancing themselves from distractions that prevent them from being effective somewhere else - meetings is one of those.

Fair Representation in Team Retrospectives

2007-06-06T19:58:00.000-07:00

Joe: Yes, we have had problems and still have them. Jane: What problems does your team have? Joe: There are many - I can tell you my problems. Jane: Alright, so what works well for your team? Joe: Again, I can tell you what works well for me, not sure what works well for others on my team. Does this conversation sound familiar? It happens almost on every project in some form or other. One of the other forms of this debate is what a lot of team members have with themselves. Some of these are again very usual questions - Is it just me who has these problems or do others have these as well? I am not being able to achieve this objective due to this obstacle, is it an obstacle for others too? This practice does not have any benefits for me, how do I convey this to other team members? To address these questions a lot of teams have a retrospective. In agile teams that work in short intervals or iterations, as they are called, an iteration retrospective is held. Retrospective is a forum where teams members discuss what went well and what didn't go well. The idea is to get the issues out in public and then to vote on them. Then the team picks the top items and takes some corrective issues to weed those problems out of the team. One pattern that I have observed is that due to very obvious reasons only the top three or four of these are chosen and assigned to people. The rest, which are supposedly not that important, don't usually get acted upon unless they become detrimental. So far, so good. The problem, however, is that if a typical team has 20 developers, 2 QAs, and 4 Developers the issues that are BA or QA related will never have enough votes so that they can be acted upon. There are two solutions that I see for it:

Have a separate retrospective for each group.
Divide the issues into group and have people vote on them. Choose the top 3-4 issues from each group and solve them out.

An obvious demerit of the first issue is that problems surface up but are discussed and resolved in silos. This is not good in long run as the other team members will never get to learn the issues that others typically face. This is bad for learning, growth and maturity of the team. The second approach is not free of demerits. It is a typical reaction that people think they are wasting their time if the issue is not related to them. In my opinion the second approach is the best if the team members have to grow and the overall maturity of the team is to be increased.

Deliverable vs. Consumable

2007-05-10T07:35:00.000-07:00

What's the Deliverable you expect? What's are the deliverables of this process? Should I document this in some form of deliverable? These have been some the questions that others have asked me or I have asked myself for as long as I have worked. The common theme across these questions is the word deliverable. Software development process has come to a state where more and more professionals are now starting to appreciate that it is the end product (working software) that matters the most. The tools we use to get there are definitely important but the documentation is only valuable as long it is reflects the the current state of understanding and is used during software development by the people who are actually developing the software. This realization has prompted the industry to start using practices that are lightweight and produce working software in smaller and frequent cycles. Companies like ThoughtWorks (www.thoughtworks.com) are leaders in this space and are busy innovating the methodologies of business analysis and software development to fundamentally shorten the lifecycle of value delivery using software. As a big fan of these lightweight but agile practices that ThoughtWorks has been a pioneer of, I try to follow them as much as possible and have been very successful at it. It's a mindset that's a little revolutionary because of its simplicity but sometimes makes people a little uncomfortable in the beginning due to its pace, flexibility, discipline, and decentralization. This approach has crafted out a set of practices and methods that are collectively, and quite aptly, know as the Agile methods. As eluded to earlier, one of the characteristics of these Agile methods is to be lightweight - do only what is necessary. This is a hard thing to do, or at least at the start. As an Analyst my instincts tell me to transfer all I know about the client, processes, and problems in as much detail as I can. They also tell me to document these so that it's not just in my head and other people can have access to it at their leisure. This is, however, an activity that is not as productive as it may seem to for very many reasons. Top three of these are:

Time/Effort - It takes a lot of time and effort to document it all out,
Life Span - In today's world, things change at a fast pace and hence the docs may become obsolete very quickly, and
Attention - Very few people have time to read the docs. The attitude generally is, "Why don't you tell it to me, rather than have me read all this."

Every deliverable that I am responsible for has to go through this filter of Time/Effort, Life Span, and Attention. This saves me a lot of time, which I can then invest in understanding the domain of my client, building relationships, sharing ideas, and solving problems, etc. This is the first stage of getting lightweight. The second is to keep the necessary document just long enough to provide relevant details. I don't write epics anymore. That's where, typically, stagnation hits. This is where I have felt choked a lot of times before, failing to improve the effectiveness and agility any further. Recently, I met a gentleman from ThoughtWorks, Inc. who has taken a different view on the whole value chain. Instead of looking at it from the push perspective he looks at it from pull perspective. What that means is that produce only what is required and when it is required. Think of yourself not as being responsible for a deliverable, but being responsible for a consumable. Not only does it keep the process lightweight, it also prevents it from being outdated.

Importance of a Business Case

2007-05-05T07:03:00.000-07:00

In one of the previous notes I had briefly talked about a Business Case. Its importance is, however, surpassed by only a working piece of software that delivers the intended business value. As a Business Analyst in my earlier days I had seldom cared about asking for and reading the business case for any of my projects. I guess, it was always very "obvious" to me that there's got to be a good enough reason for undertaking this project that I have been asked to contribute to. Any chaos on the project, which is not unusual a lot of times, never ever made me wonder if things were in place at the helm; they always seemed to be. I always trusted the leadership and was just too impressed by the techniques that some of these leaders used to run these projects. But, slowly with time this made me realize one things - there's something that sets the tone of the things to come right from the onset and governs the confidence and direction with which the team moves ahead. It's the Business Case. There is not a single set-in-stone format of this document. Still, it should answer the following questions for the reader:

What's the problem?
What's the budget?
What are the timelines?
What are the perceived benefits?
When will we consider these benefits to be achieved?
Who are the key people involved and what are their responsibilities and role in the proposed project?

Some of the benefits of a business case is that it:

Helps to remind the team of what valuable and what's not and brings them back from any digressions.
Helps to sustain the morale of the team members.
It keeps the possibility of scope creep to a minimum.

A business case is a vision document that outlines the final goal, an inspiration to undertake the project, which is often expressed as a problem statement. It's one piece of document that, for the reasons stated above, every team member regardless of their experience, age, and tenure should have access to and handed out as the first document. Ask for it!

Engine and Bells & Whistles of Software

2007-04-29T18:22:00.000-07:00

Requirements of modern systems have come to be so complex in the last few years that the word 'requirement' itself probably needs to be replaced with something else. At the very minimum, the requirements need to be differentiated between the core and the cover, atleast. For lack of better terminology I still use the word(s) Engine and Bells & Whistles. By using these words I do not want to portray that the latter are more annoying or less valuable than the former. But I certainly want to differentiate between them based on the criticality. Let's take an example of an application that is used to record the clock-in and and clock-out times of a workers and their other shift activities. Some of the desired pieces of functionality may be:

Log shift activities
Log in and out times
Generate XYZ Report
Export Data to Excel
View Data in a Range

The above pieces represent the nature of a few types of functionality that are often found on projects. One of the practices I that I follow and recommend to others is of course to determine the business value of each of the features desired. For different businesses the value of each of the above features will be different. The other practice is to seperate the features into engine and bells & whistles after you have determined their business value. So, in the above example Export Data to Excel or View Data in a Range can be a bells & whistles feature if it has very little business value. It is a feature that most likely got added because all the other applications in the industry may have those.

This often gets skipped, but is very helpful for many reasons. Some of them are:

More experienced people can be handed the responsibility of the engine components.
Bells & Whistles can always be used as filler features when engine feature(s) planned for an iteration of development are over.
These are often good pieces that can be used to get new team members upto speed on code. Let's not forget that bells & whistles can be very complicated features to implement sometimes.

There, probably, aren't any rules of thumb by which a feature can be classified as bells & whistle. However, there are certain hints that can be used to figure it out. If the business value is very little compared to some of the other features and/or if the feature being asked for has its inspiration from a lot of commercially available applications, there are high chances that it may qualify as bells & whistles.

Process Study and Client Interviews

2007-04-02T17:35:00.000-07:00

Have you ever asked a BA about what (s)he does and the biggest challenge they have had? I have asked many and the majority of them told me that gathering requirements by interviewing clients is one of the primary tasks. The challenge that most of them face is either information overload or not getting enough information. I have been in both situations and have come to realize that eliciting and distilling information is very complex because the level of granularity is not consistent across the interviewee base. A solution to distilling information is to enforce a consistent level of granularity while talking to users and clients. This doesn't mean that the granularity has to be the same across the different roles; it just has to be the same across different users/interviewees withing the same role for it to be the most effective. In order to guide the consistency, it is very important to have a list of questions ready and compiled before hand so that as an interviewer you can get a feel of them. A quick review of questions is all it takes to make a decision if you need to go one level up or a level down in granularity with questions. There's three (3) different styles of interviews that you can follow - structured, semi-structured, and unstructured. What do I mean by that and what are their merits and demerits.

Structured - These are generally yes/no, fill in the blanks and data collection kind of questions. The nature of these questions make the interview process seem like an interrogation rather than a knowledge sharing session. Problem almost never come out using this format.
SemiStructured - Problem come out, which don't in a structured interviews. It is a very efficient two way communication process.
Unstructured - Without guideposts the chances of straying are very high. Also, it is very important for the interviewee or the respondent to be able to sense the direction you are going in to frame their answers correctly. Unstructured interviews don't have that benefit.

In my experience a semi-structured interview is the best fit for the kind of information that a Business Analyst is generally interested in. This is almost a free form discussion that is primarily time-boxed and secondarily scope-boxed. By that I mean that in a certain time period of interaction you plan to touch a set number of topics armed with a few questions upfront and then asking questions as an when the information is revealed by the interviewee. And, if you don't get to ask all the questions you try to interview again. Choose one of these styles based on the following:

Availability of users/interviewees.
Subject Matter Expertise.
What do you aim to understand - process or problem

Answer the following question before you go for an interview. Do you want to understand the problem or do you want to understand the process? The distinction between the problem and the process is more important than what's obvious. The study of a problem needs an entirely different source than what is required to study the process. Understanding the process requires interaction with the people who actually carry out the tasks, but it's the managers that usually contribute the most to understanding and solving the problems. The reason is simple, people who actually carry out the task are the ones who the know the most about it but at the same time usually don't see any problems with the current processes. They know so much about the proess that they justify each and every step of it and, hence, nothing ever seems to be a problem.What's the kind of information you are looking for; primary or secondary? Information is classified as Primary if you communicate with the person who carries out the tasks. It is secondary if the person you communicate with is not the one that carries out the tasks but has either been the consumer of information in the past or has just been an observer or a supervisor. Answering the above two questions and preparing for it is useful since the objective is very clear at each and every step of the study and interview process and focus is maintained. There are two symptoms of incorrect focus and it is very important to identify those. These are:

Incomplete understanding of the process/problem, and/or
Indecisiveness

There's, typically, two kinds of statements that should prompt you to seek different people to talk to. These are:

I don't know, or I am not sure.
I can't make that decision.

Next comes the part of documenting the process study and client interviews. With the processes in the industry out there being as sophisticated as they are, there's no one prescribed format to record the findings. Most of the business problems are unique and require a fair bit of tweaking of either the existing templates or creating new ones. The objective of creating this artifact is to take down notes for each of the process steps and make a note of where this information came from, just in case if this has to be verified later on. The idea is to have enough information that can serve as a reminder and a, without having to ask the basics again and again. The idea is not to make this artifact a training document for someone in the team. Overall, the document should be lightweight and just in enough detail to be able to make educated estimates from.

Business Relationships - What's your Mantra?

2007-03-30T17:37:00.000-07:00

In one of the previous posts I wrote about the role and the responsibilities of a BA. One of the responsibilities was to be liaison between the business and the technical teams, which also happens to be the most commonly understood and agreed upon responsibility of a BA. This also entails developing good relationships with both of the groups. As the size of the corporation or the team grows this starts gaining even more significance. Good relationships can get things done faster than usual and usually people go out of their way to get things done for you and help you out. Although, I haven't ever tried to measure the size of the group beyond which communications starts to go down in efficiency and tasks start to take unusually long because of dependencies, I have a rough idea like everyone else. And then there are aspects of human behavior that start to project in all sorts of odd fashions. A Business Analyst also has to be careful of those and start managing the related issues. If the Development and the Analysis teams belong to the same company as the Business then the performance and delivery criteria are usually more relaxed. However, if Analysis and Development is being handled by a consulting partner from outside, both the criteria to evaluate the performance and parameters of measuring the effectiveness and pace of delivery get a little more narrow. Good and effective consulting groups usually try to eliminate chances of this happening by managing the relationships right from the beginning. Also, the key is that each and every consultant from the team is aware of the importance of building right relationships. It's a responsibility of each and every consultant and not just one specific role on the team. This is infact one of the first few things that are recommended to a consultant. Relationship building and management is right on the top of the list of essential consulting skills. Here's what once a very senior executive said to me, "You are the top of the heap, but you need to learn to build relationships with the Business to not only succeed at this task but to also to grow". So here's what my mantra became from that point on. In any consulting gig the relationship between the Business and I should be like Batman and Robin. And this is what I strive to achieve and dedicate time and energy to in parallel of doing the other very essential tasks that I have to.

Distinguish between Business Rules and Validations

2007-03-28T17:22:00.003-07:00

A good set of requirements should always specify the Business Rules clearly. Business rules are a very crucial thing to understand. What are the Business Rules? These are some of the statements or questions that IT professionals get to hear very often. I can't agree more with the first and the second statement. Business Rules can make or break the effectiveness of a software application. That's how important they are. However, the definition and look and feel of business rules is probably still not clear to many Business Analysts. Or so it seems when I read a lot of requirements. Ocassionally, I have also seen that there's a lot of confusion between business rules and validations. Let's take an example for context. Let's say as a BA you want to understand and document the requirements of a device to measure the concentration of gases that flow through a medical systems device. Here's a few statements:

If the unit value is selected as '%', the value for the gas should be between 0 and 100. If the unit value is PPM (parts per million), the value for the gas should be between 0 and 10000.
If the gas flowing in the system is oxygen then the precision of the value should be to one decimal place. If the gas flowing in the system in not oxygen then the precision should be to two decimal places.

What's the nature of the statements above? Are they Business Rules? No, as much as they seem to be, they are actually not. These are simply validations that have to be performed. These are a level deeper in the granularity than the business rules. Validations have business rules as their origin. Business Rules are constraints that influences and regulates a process. Validations are how these business rules manifest themselves. For the examples above the business rules can be written down as:

Gas flow concentration is measured in Percent or PPM.
Precision of measurement is different for oxygen and other (non-oxygen) gases.

This by no means mean that the details are being omitted here. It just means that the details are being deffered to the validations or the acceptance criteria section of the requirements document.

Why is this difference so important to understand? Well, as a Business Analyst one of the pitfalls is getting into details too soon or getting too technical. In the interest of time with the client or keeping the communication restricted to plain and simple English it is very important to understand the process in as simple terms as possible. This also increases the chances of the business representative to actually read the requirement and comment on its correctness.

The Person and The Role

2007-03-19T07:00:00.000-07:00

One of the surprising things that I come across during my interaction with professionals is the confusion between a person and a role. It's sometime also not as much a point of confusion as it is about not realizing the importance of distinguishing between them. Abstraction is the Key For an analyst the importance of making a clear distinction between a person and a role is never more important than while studying an organization's processes, both As-Is and the To-Be. This, in my opinion should be one of the first few things that a BA should find out about their client(s). I am not arguing that it is not important to know the person and the people involved for very obvious reasons, including relationship building, etc. But, as an Analyst, it is the Role that is of more interest and not a specific Person. It's the role that a processes is designed after, mostly, and not the person. If it's not, then that's how it should be. How many times have you heard statements like these?

That's not my job.
I don't have the bandwidth for this.
There's only so much I can do.
The bottleneck is that right now it's just me handling all this.

One thing that is common across all these statements is that each of the speakers is describing the problem visualizing either themselves of a specific person. And this is why a lot of times a lot of processes at a lot of places never get fixed. Talk Roles To counter such things, the first things that a BA should do is to get a Person to Role lookup ready for any organization. All the process diagrams and workflows that are produced as deliverables by a BA should have the roles and not the names of the people. While reviewing one of the process models of a client, I noticed that the BA role was missing from one of the key meetings. As expected I raised a flag and was told that it is because they don't have a BA. Again, as I said earlier, this was a statement that reflected confusion between a person and a role. This brings me to one of the other relationship aspect between a person and a role. A relationship between these two is many to many. A person can have many roles and a role can be played by a group of people. In other words, John Doe can be a PM and a BA and the role of Production Support can be played by a group 0f 3-4 individuals. Although this is a very trivial thing to write about, I find it worthwhile to express my views on it. Making this distinction clear upfront and keeping focus on it:

Brings out more information related to processes and the pain points. People feel comfortable in discussing the responsibilities of roles rather then a person or themselves.
Makes decision making more objective. Tasks are approached and analyzed in an impartial manner.
Communication becomes more effective.

One of the biggest advantages of getting to roles right from the beginning is that this prepares the client/customer for user modeling (personas and scenarios), which is yet another essential step towards designing and developing effective processes and tools.

Business Process Requirements - It's not a Trade-Off Triangle

2007-03-14T19:02:00.000-07:00

For a Business Analyst it is not uncommon to spend most of his/her time concentrating on Requirements and Processes. I always hear it from people that a BA gathers and identifies/captures system requirements. Actually, very few go beyond the assumption, saying it out loud, that a BA also understands the process part of the problem. Business Analysts are typically seen as the people who will take care of the nitty-gritty when the goals have been identified and a decision has been made about what is to be developed. It's just the how part that a BA is thought to be responsible to figure out. And this is where the problem begins. Projects get executed, money is spent and yet sometimes the goal is not achieved. Either the system does not deliver the business value or even if does sometimes it's an overkill for the benefits it brings about. The overall picture, sometime, is that that there's a big disconnect between what the business objectives were and what's created as a solution to meet those objectives. This is a risk that is so often realized nowadays that technologists have become callous to missed deadlines, cost overruns, and even complete failure to meet the business objectives, which is otherwise also know as project failure. Dissection So why does this happen so often that projects fail; either they miss the targets or they end up delivering something that has very little ROI? Is it because the PM don't evaluate the business plan or is it because the SMEs (Subject Matter Experts) are really not SMEs? And let's not even drag the BA into the discussion here because (s)he just did what was asked to do. That's the mindset that is prevalent in the industry. None of the roles - PM, QA, BA, etc. encompass any responsibility to forcast and evaluate the ROI. And just in case this team happens to represent a consulting firm they could care less. They would just manage, understand, develop, and support what they are asked to deliver. That's the perception in the industry, at least from what I have been hearing. Solution So how can we ensure that this doesn't happen the next time on our next projects. I'd say, get the BA and let them do what their title cries out loud; let them be the business analysts. A BA should first tackle and understand the business and then the process and requirements parts of the problem. A BA should be very clear of the challenges that the business is facing for which they want a solution. Specifically a BA should ask the following questions:

What's the business this client is in?
How do they provide value to their customers or how do they make money?
What's bothering them?
What are they good at?
What do they want to do?
How do they know if what they want to do is what would help alleviate their problems?
How would they know if what they did is helping them when their proposed solution is implemented?
What are the priorities in the solution space?

This list of questions is much larger than what's written above. The idea is that a BA should be introduced in the process right from the beginning and should concentrate on understanding the state of the union (as one of my colleague calls it) and the goals and objectives of the project. It is the responsibility of a BA to make sure that they stay on top of the business priorities. Process analysis and requirement analysis by a BA without getting involved in business analysis will expose the team to a huge risk.

The quintessential BA

2007-03-13T11:05:00.000-07:00

The quintessential BA

The following are some actual job descriptions I have come across over the years on the job boards related to Business Analyst positions.

--- 5+ years of experience with equity and annuities.

--- Must have solid 7+ years with Healthcare specifically claims, provider and insurance.

--- Should have worked for a minimum Ten years in a telecom or communications field.

The question is

“Is there such a thing as a generic BA who can function across industries?”

In other words

“Is it necessary to posses a specific domain knowledge to perform as a Senior BA”

For starters lets look at our fictional Generic BA, Joe.

Joe has worked for many years with a software product and/or services company. He started as a junior BA straight out of school and learned everything on this job. He has mastered the art of people skills. He knows all about requirements gathering, cost estimation, functional and non functional specifications and spends his days storyboarding, brainstorming, building use cases and working with activity and sequence diagrams. He accompanies select sales force to capture client requirements and grievances. He easily translates requirements into technical specifications and can fluently talk GeekSpeak and ClientLingo. He organizes meetings, facilitates discussions and consolidates notes. In a nutshell he is the perfect BA for his company.

But Joe has hit a ceiling with his company and is tired of his boss. Joe wants a change. Joe wants to move to NYC from SFC and work for an Asset Management company as a Senior BA. Joe applies for a position that matches everything on his resume except the dreadful 5+ years in Finance or Investment Banking domain. Would it be wiser for the bank to hire our stellar BA, Joe over an average BA who hasn’t shown much potential except the requisite experience?

Tough call. Depends on the situation. Whatever the job requires. Yada yada yada…

Joe is pissed. He should be. Or should he not?

Well it really, really depends. You can learn the terms of trade on the job and master the lingo. You can pick up threads and find your way through the nitty-gritty’s of the business. As long as you know the basics and techniques you can adapt to pretty much any new environment.

But sometimes; scratch that, most of the times the incumbent is expected to jump-start and contribute from day 1 and knowing the domain helps, helps big time. It shouldn’t supercede the inherent talent and caliber. Therefore the employers have to ask themselves, “Is this person the quintessential BA I am looking for?”

This decision, as always, is not an easy one.

Card Wall - It's not Reversion

2007-03-12T07:00:00.000-07:00

A few weeks ago I was with a big client coaching and helping them transform their analysis and development activities so as to be able to respond faster to the market and outpace the competition. After the first few days one of the client Project Managers came up to me and expressed his surprise and lack of faith in the style of working and the practices that I was demonstrating and recommending to them. To take a step back, in the last couple of years I have become a big fan of using paper, pens, tables, and walls for as much as possible. I have seen business goals and processes being spanned over the walls using a simple marker and lots of cards of different colors. Having done it myself, now on multiple projects, the effectiveness and the participatory style of this elicitation technique has proven its power and reliability so much that I take a lot of pride in demonstrating the technique to solve real-life problems. One particular thing that can be done with this technique is to set up a status wall of tasks for any team. This wall can have a simple 3 column layout with the columns being Backlog, In-Progress, and Done from left to right. Each task that each team member is supposed to do in a given timeperiod (a week or two or may be even a month) is added to the Backlog and as they are picked up by the indvidual team members these cards are moved into the In-Progress column and subsequently to the Done column when they are completed. This is one of the simplest ways you can track the progress of a team that is also very visible to anyone and everyone. It can also be accompanied by any flavor of a graphical progress report that can also be hanged alongside or in the vicinity. This particular client had already spent a few days with me using almost similar techniques to talk about the vision of the team/products, roles and responsibilities of the team members, etc। And then we embarked on the actual transformation process। This is when the client project manager said something like,

I just don't understand why, in this day and age when we have all these electronic means and tools to track projects, somebody would use a style that not only antiquated but also inefficient. This is a place where we gets things done; nobody has time to do this

This left me thinking and wondering if there were people on the earlier teams that I had worked with who did not express their astonishment। But most important of all, this led me to write about it today so that the power of putting pen to paper (as we used to do earlier) is not lost and underestimated. Here's a few reason why I think this technique works:

It's simple and fast - all you need is a few markers and index cards and a dry wall. Moving things around is very simple.
It's highly collaborative- everybody can participate and see their ideas/tasks make to the wall.
It's visible to everyone - team member don't have to log in to any system to see the progress.
It's collectively owned - no one person owns the card wall. Everyone updates with their progress.
It's current - the chances are that the next time the team meets somewhere close to the card wall, they'll update it right there and then. This keeps the card wall better updated than any other electronic tool that I have seen and used.

This leades to an enviroment where critical data is always posted in big bright format. The idea that usage of pen and paper rules out utilizing the electronic tracking tools is a misconception. These are complementary to each other. Card walls just make the process of processing, managing, and displaying the vital information to all the consumers very easy and effective.

Scope Vs. Scale

2007-03-08T15:23:00.001-08:00

Scope is probably one of the most overused words in the lingo of a Business Analyst and a Project Manager. Scale on the other hand gets used very little. So little that the difference between scope and scale is not very clearly understood by many. The way I see it is that scope is about variety and scale is about numbers. So what do I mean by that? Let's take an example of building an airport. Some of the main components of an airport are the runway, tarmac, terminal building, and jetways. These diffrent types of facilities add variety to the structures required to be built. On the other hand the number and size of runways, terminal buildings, and jetways determine the scale - bigger the number larger the scale. So, if I were to add a light rail system to the airport, I am increasing the scope. If I double the size of the terminal, I am adding to the scale. Why does this difference matter? A clear distinction between scope and scale enables better decision making. Let's take the example of a jetway. The justification of a jetway is to enable the passengers (un)board the plane from the terminal building. This can probably be achieved using a jetway with one door, which is not only cheaper but also simpler. However, if the requirement now suddenly changes to enable customers (un)boarding from two doors of an aircraft it will increase the scale of the problem. The scope is still the same. I have seen many a debates and back and forths between the clients and development teams over issues that are perceived to be an increase of 'scope', when they actually are an increase of 'scale'. Scalar enhancements are often easier to tackle because it is often easier for the client to understand that given the usage they may be spending more time and money than the return, at the moment. In such situations rescale the problem, don't descope it; says so Jeff Patton in his write-up titled Finish on Time by Managing Scale that is available at: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=10330 Amongst the many advantages the prominent two of this approach are better client relationship and a more useful product. This is of course given the assumption that the business value of the feature is identified correctly beforehand.

Stand-Up Meetings: Progress of Team Vs. Status of an Individual

2007-03-07T06:34:00.000-08:00

One of the most powerful tools and techniques, amongst many more, that I have come across over the last few years has been the Stand-Up meetings. Stand-up meetings are literally held standing up; each and every team member stands up and the team forms a big circle looking towards each other. There's three questions that each team member is supposed to answer:

What did I do since we last met yesterday
What am I planning on doing between now and until we meet tomorrow
What obstacles need to be removed to accomplish this task, if any

An ideal stand-up should last no more than 15 mins. And the goals of the meeting is not status update to an individual as it often is believed to be. The goals of this meeting is to let your team know of the progress, share your obstacles with the team, and get your day and tasks committed to and publically timeboxed. So, why am I picky about the Progress Vs. Status mindset? The answer in short is that it influences the attitude of the team members. When it's about Status, individual team members say their part and sort of zone out right after that. But when it's about Progress everyone is curious to know what it is and how they can benefit from it. There's a good write-up on stand-ups by Jason Yip available at http://www.thoughtworks.com/PatternsDailyStandupJason%20Yip.pdf Jason has the pros and cons of having these meetings in mornings and evenings. I have been involved in both morning and late afternoon meetings. As such there is not a prescribed time for a stand-up, but I find the morning ones more effective for the following few reasons:

It's a good start for a day, much more disciplined. I get to work on time to ensure that I don't miss the meeting.
I look at the day ahead with 8-10 hours and hence I am more focused.
With afternoon stand-ups the rush to finish work is, usually, during the late mornings and that distorts the spread of work load; it becomes more uneven.

What is a Business Analyst?

2007-03-02T20:37:00.000-08:00

The role of a Business Analyst is often the most underestimated in the IT industry. If not that, it is not uncommon to come across so many different definitions of the role that the BA's often find themselves in a quagmire of responsibilities. What makes the problem a little serious is that, in an typical IT shop, almost everyone else thinks that they can do what a BA does. At the face value, it is not untrue. But then there's a counter to that, who can not do anything that others do. But the questions remain; do they have the time and the passion to do it, and the most important of all, are they good at it? So what does a BA do anyway? Kathleen B. Hass of Management Concepts, Inc. in her paper titled The Business Analyst: The Pivotal IT Role of the Future wrote that the role of the business analyst is emerging as the central IT competency of the future. And she also writes that the business analyst also serves as a liaison between the business community and the technical solutions provider. Doesn't seem too difficult to do and is thought of as the only job of a business analyst. There's so much ignorance around the importance of the role in the business solutions lifecycle that they are often referred to as glorified secretaries. There's much to a BA than just being a notes taker and a meeting organizer. A BA ensures that the team understands what the business wants to achieve and how the value will be delivered. Documenting the requirements just happens to be a process to capture this piece of information for the team to understand and refer to. It just so happens that the prevalent form of documentation in the industry is outdated, one which lays stress on producing tons of paper with fancy names like the Business Requirements Specifications, and the Functional Requirements Specifications. A typical BA spends so much time in writing these documents that no wonder they seem like secretaries. In my opinion the the primary responsibility of a Business Analyst is to understand the business needs of their clients and how the client delivers value to their customers. It is usually an activity that requires high energy, excellent time management and organization skills, and an ability to learn new business and domains quickly, especially if the BA is also happens to be a consultant. As the business environment around us is changing and the competition is becoming cut throat, a typical business solution lifecycle has become very short than what it was a decade ago. Today, companies need to provide added value to its customers more than just once a year. Typically, a BA is also the person who makes an objective evaluation along with the customer about what is a priority and why. This person has to be able to understand the risks and rewards of the business and what determines their play. And this is also the person who understands the power and limitation of the tools and technology available to help the customer achieve their goals with the associated costs. It is just not the project manager who should worry about these. It is the responsiblity of a BA to provide the data required to assess those costs to the Project Manager. These tasks take more than just writing the requirements and being a channel of communication. It takes an attitude of problem solving and being an agent of change, it takes a sense of ownership of the problem, and a desire to make the processes and people around you more productive. Kathleen Hass's paper is a good read that answers a lot of questions about the role and responsiblities of a BA and it can be found here. Update I found a job posting for a BA on Southwest Airlines' website, which by far is the best description of responsibilities of a BA that I have seen. This job posting can be accessed at: http://www.southwest.com/careers/6655sy.html In case this link is not working please click on the image on the right to see a screenshot.

Why at all and why now?

2007-03-01T20:44:00.000-08:00

There are numerous blogs out there that deal with the art of software development. And around this art are other blogs that look at it from the perspective of project management. But none so far, that I know of, ever have the perspective of a Business Analyst. This blog shares my views on the definition and the importance of the role of a Business Analyst and the best practices.