Agility and Scrum: Conversations outside of IT Software World

Through some of the corporate training work I had done, I got a referral to work with a couple of professional entrepreneurs in India. They were trying to introduce efficient ways of working through a combination of process improvement concepts and tools in the construction space. As part of the initial interview, I found out there was an executive level interest in increasing focus on building people up with experimental ideas to pilot and pivot! Naturally, I explored the notion of Scrum or Agile and there was an almost immediate dismissal of these concepts. The two people echoed, "I am not sure how much these IT thoughts apply in improving ways of working!"

Although our conversations never materialized in any work after 3-4 months, I felt compelled to write about how much work Agile and Scrum must deidentify themselves from their use mainly in the IT industry. I guess the Agile Manifesto principle, "Working Software over Comprehensive Documentation" has served itself to exclusively apply to the software product world. Perhaps the lack of diversity and inclusive thinking in the original Agile Manifesto thinkers has created a stigma about the Agile ways of working to the IT industry. However, as I have already mentioned about Agile being applicable in a non-IT setting (Rajagopalan, 2013), agility can be extended to healthcare (Rajagopalan, 2021). For example, replace "software" with "healthcare" to read as the "Working Healthcare over Comprehensive Documentation," and the principles can extend outside of software development.

Both Agile and Scrum are about empowering the teams to have a working agreement to solve a problem identified (or self-identified) for them by the organization. If the organizational culture is conducive to failing forward rather than punitive, any industry can apply these frameworks, which shouldn't be restricted to any industry. Consider, Andon Chord, that originated in the manufacturing assembly where all works stops to ensure that the team collectively engaged in problem solving! Examples of Andon Chord from Lean Manufacturing have found themselves applicable in many industries with the simplest example of "Stop Requested" in public buses! So, Agile and Scrum are both about the 'ways of working' where the teams are enabled to improvise with experiments to pilot and changes to pivot. 

Now, if you look at Dalmia cement, there is a lot of information about their partnership engagement with KKR (2016) that made them prosper. In that video they talk about five pillars such as learning & humility, teamwork, speed, excellence, and transparency (Alchemy: The Dalmia Bharat - KKR Partnership, n.d.). These are directly related to principles of courage, focus, openness, respect, and commitment of Scrum which emerge from the agile empirical pillars namely transparency, inspection, and adaption. Similar concepts can be seen in the US based Holcim Group, one of the famous cement producers where the very first sentence talks about the industry's focus on using agile management.

Transparency is already identified in the Dalmia/KKR partnership as pillar #5. When you look at the thoughts on speed, they talk about having a 100-day plan, metrics, process, roadmap, and experimentation! It is about the ways of working which enable the second pillar of teamwork. The focus of experimentation without the fear of failure is already mentioned that talks about trust, communication, and teamwork without which excellence does not come in. I challenge that the principles of agile and scrum are already applied but not understood. If the right tool and the framework is further identified, think about how it could improve! 

Example Scenarios presented by Dr. Sriram Rajagopalan

Similar examples are found in other industries as well. The Food & Drug Administration (FDA) allowed the use of Agile in Life Sciences and Healthcare (Deloitte, 2020). Here, there were focus on adopting risk- based governance in an iterative way addressing toxicology and pharmacology safety in clinical studies, adverse reaction protocols in later phases, and occupational hazard protection before, during, and after drug development. Centrus Energy, an international commercial nuclear power plant completed their R&D initiatives using Agile approaches (Stracusser, 2015). Telpak (n.d.) using the robotic process automation (RPA) for good manufacturing practices (GMP) and CSol's (n.d.) focus on laboratory insights for good laboratory practices (GLP) are all examples of Agile mindset. In fact, I see these agile approaches pave their foundation for the general automation manufacturing protocols (GAMP) as well. 

But such non-IT industry focuses need to be highlighted more! The stigma that Agile and Scrum applies to IT and Software product development is continuously emerging with DevOps and SAFe with too many technical terms proliferating solution-mindset in non-IT industries. So, many practitioners have more work to do! Who is willing to partner with me to write such case studies? 

References

Alchemy: The Dalmia Bharat-KKR Partnership (n.d.). https://www.youtube.com/watch?v=gxXxtMYKprg

CSols (n.d.) Agile development in Laboratory Informatics. https://www.csolsinc.com/blog/agile-development-in-laboratory-informatics/

Deloitte (2020). Validation using Agile in the Life Sciences and Healthcare Industry. https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/LifeSciences_Healthcare/IE_RA_Agile_0320_.pdf

KKR strengthens association with Dalmia (2016, Jan 15). PR Newswire. https://www.prnewswire.com/in/news-releases/kkr-strengthens-association-with-dalmia-565397881.html

Rajagopalan, S. (2013). Agility outside of software world: A case study from a theatrical play. https://agilesriram.blogspot.com/2013/05/agility-outside-of-software-development.html

Rajagopalan, S. (2021, Mar 8). Agility in Healthcare Services: Insights from Clinical and Surgical Settings.

Straçusser, G. (2015). Agile project management concepts applied to construction and other non-IT fields. Paper presented at PMI® Global Congress 2015—North America, Orlando, FL. Newtown Square, PA: Project Management Institute

Tekpak (n.d.). Pharma Competency. https://tekpakautomation.com/pharma-competency/

Agile needs to understand and focus on agility more

Over the last few weeks, I overhead a few practices such as the following while claiming to practice agile.

a)       Not finding the tasks in the sprint backlog for sizing the user story

b)      Evaluating the definition of done during almost every sprint

c)       Focus on the sprints and lose the value not delivering on committed time

d)      Not factoring capacity into account in a velocity driven planning

The major focus of agile is on maximizing value to the customer. This is stated as, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” To accomplish that goal, it is imperative to ensure that we exhibit agility rather than claim to practice the so-called Agile paradigm. When the focus is on this value maximization to the customer, how could the above practices that fail to add value to the customer be considered agile practice?

Maximization of value means within the agreed timebox, the team self-organizes to add the appropriate tasks. The scrum master acting on the team’s behalf needs to hold the definition of done articulated ambiguously by the product owner. Similarly, the product owner needs to be held accountable to the larger committed timeline to the customer not losing focus on the slips in the timeline due to losing velocity in every sprint.  The scrum master needs to hold the product owner responsible for capacity planning in a velocity driven team rather than a commitment driven team.

If the principles recommended above are not upheld, then claiming to be agile is an understatement. This is because the maximization of value delivery with a focus on customer is falling apart. Some of the root causes are the following:

a)       Thinking that a team is agile just because of the use of a specific tool or adoption of a specific recommended ceremony.

b)      Merging the crucial roles of scrum master and product owner in one person who keeps neither role in check.

c)       Addition of new team members not sharing the same norms disrupting operating rhythm.

d)      Allowing the flexibility to let the team not meet the required commitment because it can always be picked up in the next sprint.

Going to the basics, if the focus is on value delivery to the customer, then, it is important to not lose the focus of time, scope, quality, and cost and the risk of non-delivery on these elements. Increasingly, as agile gains mainstream focus, it is indispensable for the agile team to understand these considerations and not just adhere to agile terminologies. Only when one understands these principles can one appreciate when to stay agile, when to adapt practices, and when to recommend going with traditional approaches. 

Essential Leadership behaviors for Agile Transformation

In the recent Scrum Coaches Retreat that I attended, I saw a pattern where the majority of the topics presented for discussion centered on organizational transformation and implementing agile correctly. The topics ranged from change management traits for individuals and organizations, executive leadership behaviors, coaching approaches for executive leadership, coaching for non-technology groups to implement agile, facilitation techniques for team trust, and scaling agile for coaching within an organization. Having established, led, and managed a program management office (PMO) in a healthcare IT and professional services industry and with a strong desire on leadership behaviors through project management and product development, I joined the team on this theme seeing an increasing focus around executive leadership behaviors for leading organizations to embrace agile successfully (“Build an Agile Organization Executive Coaching”, 2013).

Following the agile principles of user story development, our group with backgrounds from multiple industries began identifying the major categories of persona in today’s leadership that lacked understanding or came with a traditional mindset in transformation. These observations were later shared across the various participants from numerous countries during our daily retrospectives to further refine our persona categories. The major themes of persona classification of executives evolved are listed as follows that I have reordered in a continuous spectrum of the knowledge of agile in their implementation challenges.

Resistant: The executives that fall into this category are those that have a generational gap leading to a resistance in change. The relevance to current ways of managing projects or understanding product development is not in the radar screen for taking the organization to the next level. These leaders are more task-oriented managers than leaders who feel challenged that agile may not add value. “It has been working for me and so I see no need for agile” is the theme behind such leadership.

Never heard of agile: The executives that fall into this category are open to ideas but are unfamiliar with the agile framework.  This group’s lack of understanding may arise due to many reasons such as their own personality towards new learning, lack of initiative, and firm’s industry representation to understand new trends. These members often rely on the experience of others bringing in consultant experience or another senior member to implement the transformation. If the consultant or the senior members fail to apprise of the executives of the implementation challenges in product development, skills reorientation, and the structure required for agile development to thrive, then, these executives lose faith in Agile.

  

Big Vision: These groups of executives understand that their current structure is not in line with their big vision for growth. They recognize that they need to develop products differently for competitive position of themselves in the marketplace or excelling in doing things efficiently. They have heard of the agile framework through their own due diligence to implement their growth ideas and look forward to their delegates for support.

Misinformed: Similar to object oriented programming where the subclass inherit characteristics of super class, this group of executives have had bad experience from the earlier bad implementation in their organization or in a different organization. Their “bad taste” of agile implementation shouldn’t be attributed to agile framework’s failure but the failure of those leaders or consultants that didn’t implement a stable and scalable solution.

Metric Oriented: Some executives have an instinct to not just focus on the profit motive but also establish key performance indicators. But lack of having correct types of metrics and threshold to begin with may impede successful implementation.

Insufficient Experience: This final group leans on those consultants or senior members that are brought into the organization just because they have implemented agile in their previous job. As Boyatzis and McKee (2005) noted, these high-profile members need to understand the emotional makeup of the new organization and not just their own personal success in their previous job. The reliance on a structure or set of tools that they had found useful previously but failure to understand the new organizational structure, impediments, and product makeup among others add up to the challenge of insufficient experience that these roles bring to implement agile transformation successfully.

In the end, the successful implementation relies on proper coaching of the organizational executive for leadership behaviors that they need to inculcate to succeed leading to forming a team that can coach and train the organization. If the leadership has not bought into the fundamental twelve agile principles for successful agile transformation and middle management members like functional team leads and project management not trained on product ownership, project team leadership, process governance, and client management, then, the fragile leadership should be held accountable for agile framework’s failure.

Do you think there may be other persona besides these persona classifications?

References

Build an Agile organization executive coaching (2013). Scrum Coaches Retreat. Retrieved December 17, 2013, from http://www.youtube.com/watch?v=4z_6rEkTP8k&feature=youtu.be

Boyatzis, R.E. & McKee, A. (2005). Resonant leadership: Renewing yourself and Connecting with Others Through Mindfulness, Hope, and Compassion. Boston, MA: Harvard Business School Publishing.

Chaos Control: Agility in transforming communication - SIT principle

One of the main ingredients of a Project Manager’s success is taking charge of communication. If communication is half of the struggle, then, how you communicate is the remaining part of the trouble. Recently, I observed a series of emails from several remotely distributed team members. Within a few hours, there were close to 35 emails on the same topic with various members not always picking up the latest thread and using that prohibited button, “Reply to All”. Reminding me of a war room where all members were screaming at each other, this observation is an example of “Email Noise” that serves its very opposite purpose of “Clear Communication.” Proving that emails lose transparency to project team (let alone executives), fails to hold people accountable in a situation that calls for collaboration, and loses control in prioritizing the work queue unless the project manages “takes charge”.

Agile principles promote that teams should be collocated for this reason. Besides, communication is structured to ask what happened yesterday, what is going to happen today, and what are the obstacles to reaching the goals? While change is constant and agile accommodates it, this does not mean that some basic principles of productivity management for systems development (Barry & Wyatt, 1996) should fly out the window. These principles include 1) defining the job in detail, 2) getting the right people involved, 3) estimating time and costs, 4) breaking the job down, 5) establishing the change procedure, and 6) agreeing on the acceptance criteria.

Remote distributed virtual team structures are not disappearing. Project Managers and functional leaders should become attuned to this requirement and need to be “agile” in their thinking and communication so that these team structures can still benefit from unambiguous communication that I believe can be categorized into one of the three categories – Semantics, Influence, & Technology (SIT). 

1. When the question is relatively easy (Boolean response of somewhat fuzzy but still not complex), it can be categorized as technical. For instance, checking on availability of an individual to cover for someone during a holiday period (Boolean) or requesting someone to check for review error logs to identify the cause or review a long document for clarity, resorting to email is better.
2. But, when the same requires deeper discussions requiring prioritization of tasks to meet client needs, and working on multiple projects that have resource constraints, then, communication is no longer simple requiring one to exhibit influence over what the project team may think.
3. When the team structure is distributed across time zones or the environment requires navigating through multiple client priorities, personality profiles, escaped defects noted by the client in production aggravating users, the communication evolves to semantics where ambiguity reigns.

One may find that this resonates to the principle of information theory where the Channel Capacity (C) the strength of “signal” must be increased within the allowable limits of the bandwidth in the channel (B) over the noise (N) introduced. Interested readers can review the Shannon-Hartley theorem (n.d.) for the details. The same is true even in Project Communication:

Clarity in communication is directly proportional to the versatility of the communication style of the originator and inversely proportional to the presence of verbal communication in the communication medium. 

I view this clarity in communication as the utility value of the agility in communication. An email going out asking a question or answering a question for which another question is asked in response means that communication is ambiguous. Such iterative sprints of email communication will not be interactive yielding results when influence and semantics mandate attention. Use of video podcasts, conference bridges, and plain collaborative conversations will transform the signal strength in communication. Using this SIT model, determining the right vehicle to communicate is more important than communication. To be successful in agile, one must be agile and think agile. Results will then speak for themselves.

References

Barry, T., & Wyatt, B. (1996). The six principles of productivity management - project management for systems development. 27^th Annual Seminar/Symposium, Project Management Institute.

Shannon-Hartley theorem (n.d.). Retrieved Aug 27, 2013, from http://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theorem

Agile Success Seed: Product Owner’s role to manage risk

One of the common themes that often percolate as organizations transition to agile approaches has been the identification of who owns the product vision. In a traditional project, often as recommended by Project Management Institute, effective project managers control the risk related processes as they own the project's scope. With agile thinking, this burden of responsibility shifts to the product owner because maintaining the product roadmap (starting with the vision) and grooming the product backlog is the product owner’s responsibility.

But one of the common pitfalls that I believe is a root cause for agile project's implementation failure is the inadequate orientation of the product owner to be available to do this role. Product backlog grooming is no longer entry of information in a tool or grid but is a systematic approach to handling prioritization of events that could positively or negatively impact the features in a product backlog with an unforgiving focus on business value. When products are designed and developed in vacuum without thinking through how it will be rolled out, this intense focus on business value is no longer on the radar. Depending upon who plays the product owner role (Business Analyst, Project Manager, Project Manager, Functional Manager, etc.), the nature of identifying risks morphs so much that agile projects stumble during its build (any of the releases/sprint) or as they hit the road for clients to consume. So, what are the key steps for a product owner to monitor as they maintain/groom the product backlog?

The first step to monitor the horizon for events can derail the project. The team can give some input, but the onus lies with the product owner to do the SWOT analysis and assess if the risks (Hilson, 2001) impact any of the features. This assessment could reveal new features to the backlog even on completed features. Care must be taken not to become too granular in not getting carried away for risks that impact user stories or tasks to be completed. For instance, instead of focusing on resource availability in a shared environment that may impact sprint velocity, focus should be towards eliminating risks that address training for the team to embrace agile, tools and processes to streamline communication, etc. The hardening iteration (Iteration 0) is a good place to begin this risk assessment.

When avoidance or withdrawing is not an option, the second step is to transfer the risk. Often, people skip this step and move on to mitigation right away. Sometimes, mitigation may not be the best strategy because of the detailed subject matter expertise involved, or the time commitments to deliver earlier. For example, consider the translation of voice and email notifications in foreign languages or consolidating data centers distributed globally that require specialized skills. In such cases, the third step is transferring the risk to another more informed party (e.g.: outsourcing, consultant, application service provider). 

Sometimes, transfer may not be the option leaving us to the third step of mitigation. Furthermore, even when transfer to a 3rd party is in place, steps need to be taken to mitigate the possibilities of something going wrong.  This mitigation step involves, for instance, enforcing best practice guidelines, using service level agreements, having standard operating procedures, contract review guidelines, or leveraging feedback loops to optimize the business processes, incorporate preventive actions, or take corrective actions. The sprint retrospectives are a good area for product owner that has assumed the role but not having formal product ideation training within the specific industry. This need necessitates that the product owner becomes available for the team to gather this information first-hand through osmotic communication. The more the product owner becomes unreachable, the more this risk assessment loses accountability leading to failure.

Many best practices from the mitigation strategy will still apply here, but the focus shifts more on the other responsible party, like transferring risk to an insurance carrier. For a product owner to get familiar with these trends, a more conscientious awareness of domain knowledge skills and business knowledge skills become necessary so that the product owner can make a case for the return on investment of continuing to build the product.

When none of the strategies work, the final and fourth strategy is the acceptance strategy. It is in this stage the team absorbs the risk. Yet, the product owner and the team negotiate on how much velocity can be consumed in that iteration if the probability of risk to materialize is higher. Perhaps that iteration should have more “Should do” and “Could do” features from product backlog and not do any “Must do” features. Like business continuity planning or disaster recovery planning, the product can proactively select the right mix of user stories for the team to implement to show progress but protect the team by managing risks.

All these discussions are still focusing on the fact that risk represents a threat. It is possible that risks also represent opportunities. If it is a positive risk, then, the opposite strategies apply. Instead of avoid, one exploits the possibility. Teams enhance the probabilities of opportunities rather than mitigate the likelihood of a threat materializing. Organizations prefer to share ideas to collaboratively benefit rather than transfer responsibility. 

In summary, the risk management principles are no longer just a project manager’s toolkit and are the seeds of success for successful agile implementation. They equally extend to a product owner because in an agile world, quality is non-negotiable as the product is operationalized and introduced to the customers. In fact, this is the reason why the product backlog is called risk adjusted prioritized product backlog. To embrace change, risk should also be equally invited and managed proactively. Having a product owner available to ramp up to speed with the domain knowledge of the operating business and understand the project risk management principles is inevitable for maintaining the product backlog, without which the product cannot be sustained. 

References

Hillson, D. (2001). Effective strategies for exploiting opportunities. Paper presented at Project Management Institute Annual Seminars & Symposium, Nashville, TN. Newtown Square, PA: Project Management Institute.

Thinking Differently: Transformation from Individual to a Group and to a Team

In today’s project centric, globally diverse, distributed and virtual team environment, the ability of the members in a team to collaborate is an integral part of individual’s and team’s success. Bruce Tuckerman outlined the four major stages of a team’s development as individuals become part of groups and evolves to be a team. While agile methodology may promote the need for the self-organized team within an engineering context in a product development setting, every other type of business units such as the technical operations, infrastructure, business development, sales and marketing benefit from effective team habits.

But little do many recognize what differentiates a team from a group. A set of individuals with a like mindset may be assembled to form a group but if everyone has an agenda that is larger than the common goal of the group, then, the team still not established.  The group may be best represented by the Forming and Storming stages as espoused by Tuckerman where the team is still dependent on the leader to make the decisions for the team. As the group member’s polarity on priorities is aligned towards the common business, they morph as teams entering the later stages of Norming and Performing.

Stephen Kohn, the president of Work & People Solutions of a management and training firm, along with his senior partner Vincent O’Connell consolidated their management and training experience to identify six key traits of an effective team (Kohn and O’Connell, 2007). One of these six habits includes the lateral thinking promoting how teams can innovate and invigorate by working towards common goals avoiding ineffective arguments. Often, the thinking process is associated with the systematic way of logical breakdown of ideas.

Toyota’s 5-Why principle to get down the root problem is such an example of decision tree analysis. Perhaps emanating from the control systems theory of constraints model, this hierarchical analytical thinking approach is good, but does it always generate creative ideas? For instance, how could the famous Schumpeter have predicted the “Creative Destruction” model that led to the demise of “brick-and-mortar” organizations opening the new avenues of eCommerce and eBusiness during a period of industrial automation dominated by scientific management principles?

Lateral thinking is generative and involves asymmetric pattern processing, which is not always done in sequential order, infers Edward de Bono who coined this approach in 1967 (“de Bono, n.d., de Bono, 1999). These principles are analogous to how the Agile principles promote generative behaviors through the prescriptive processes. This lateral thinking paves its foundations through six “thought” domains, called six hats. In the first domain, the team is provided with all the information available for the team to on a “fact-finding” expedition, absorb, and brainstorm alternatives. This first domain is called the white hat thinking.

The next stage leads to eliciting the team’s emotional reaction to the alternatives and decisions. Focusing on immediate reactions without any bias, this second domain, called the red hat, attempts to unearth emotional relationships. In a balanced way, the two subsequent stages evaluate playing devil’s advocate looking at the downside to selecting a solution and looking at the optimistic side of benefits of choosing the solution. These domains are called black hat and yellow hat respectively.

The next stage explores invoking additional ideas that could offset the downside and enhance the benefits like an effective and proactive risk management approach. The techniques such as force field analysis are good tools to explore for teams besides brainstorming, Delphi and Wideband Delphi approaches as they evaluate the ideas for execution friendliness if bound by time constraints. This fifth domain of additional idea generation is the green hat. The final hat, called blue hat, puts on the tactical glasses to operationalize and institutionalize the idea by streamlining the processes necessary to execute.

Great, how does these relate in real life? Say, we are confronted with a scenario of quality defects in a production application come to us. 

• Most of the “white hat” thinking would be to immediately soak ourselves in getting the details of what happened, when it occurred, how it was unearthed, etc. As the team gathers the information and evaluates the audit trail or transaction logs, the team may isolate the issue to a specific module or any systemic events. Instead of looking at the people side of the equation, effective team explores red-hat thinking evaluating alternatives and corrective action and seeks gut reactions. 
• The focus is shifting from “What happened” to “Why it happened” and “How to prevent”. Effective teams would naturally morph into wearing the black hat and yellow hat in terms of the sense of urgency to fix to address customer concern, business impact, etc. 
• While the symptom can be addressed this way, the team wears the green hat to address the root cause of the problem with a better and permanent fix to avoid similar issues affecting other customers and finally take on the blue hat to also streamline the processes by updating documents and manuals, communicating changes required, and providing training as necessary.

Isn’t it wonderful to realize the truth to the expression of “wearing multiple hats” to think differently? As you can see, the team’s ability to think laterally enhances the overall team’s ability gain trust as the organizations begin to see the team’s effectiveness in working towards the goal instead of pursuing individual agenda. As the team practices lateral thinking, the daily sprints become effective, additional meetings become redundant and unnecessary, and innovation is collaborative where together everyone achieves more (TEAM) (Temme, 1996). In these teams, the project manager becomes more of a mentor and coach, keeping the team engaged to follow the processes towards desired results.

References

de Bono, E. (1999). Six Thinking Hats. New York: Little Brown

de Bono, E. (n.d.). Thinking Tools. Retrieved April 28, 2013, from http://www.edwdebono.com/lateral.htm

Kohn, S. & O’Connell, V.D. (2007). 6 habits of highly effective teams. Franklin Lakes, NJ: CareerPress

Temme, J. (1996). Team Power. Mission, KS: SkillPath Publications

Agility outside of Software Development: A case study from a Theatrical Play

In the ever-growing need for agility in today’s business context, the principles espoused by agile Manifesto have emphasized enhanced productivity, increased customer satisfaction, and improved profitability. As noted in the previous blog entries, these principles are so entrenched from the software development practices that one of the foundational agile manifesto principles values working software over comprehensive documentation. Does this mean then that IT projects establish the glass ceiling for the agile principles?

As a member of the Chicago Tamil Sangam’s recent venture to stage a historical play, “Ponniyin Selvan” (n.d.) that was staged on May 4, 2013, we staged a historical play in the Tamil language. Centered on a course of events that took place several centuries earlier, the play presented several unique challenges that were overcome by applying some basic agile principles breaking the glass ceiling demystifying how these principles can extend outside of IT projects.  

The limelight of the play was its backdrop set in 11^th century Chola Dynasty in ancient India that weaved several challenge threads, such as the following, that needed to be collaborated to allow the finished fabric shine.

1. Preparing rich costumes, jewelry, and artifacts to differentiate the Emperor, the Kings, Queens, Ministers, and workers that required coordinated efforts to identify the needs among the actors, procure items necessary from India, and get them shipped from India.
2. Identifying the needs of the auditorium based on the play requirements, distance, transportability and audience needs
3. Designing several high-end artifacts that were transportable with easy assembly, such as preparing backdrops suitable for the play, two boats that moved, a ship with effects to display shipwreck, a palanquin as an entry point for the character, and pillars establishing the authenticity of the 11^th century
4. Rehearsing the play spread over five volumes perfecting dialogue delivery, enunciation of words, clarity of voice projection, light cues for various spots on the stage differentiating progress of characters and events through various backgrounds, preparation and coordination of musical clues, singing and dance choreograph appropriate to the characters, body language clues collaboration such as when to pass the message card or the crown, how various characters should see during critical scenes, 3 full length exams including a daylong marathon practice sessions.
5. Advertisement and marketing efforts on social media, press, and soliciting appreciation from prominent external representatives, such as the President of India, increasing the reach
6. Subsequent preparation for the main event date with food and supply for the crew, makeup needs, and transportation of goods, stage preparation, and coordination of light clues with the auditorium crew that didn’t speak the regional language, backstage line up of cast during the play informing what scene is in progress
7. Addressing challenges for audience lineup, food distribution, parking lot and law & order challenges

Do any of these resonate with agile thinking that many reserve for software development projects? Let us revisit the Agile Manifesto (n.d.) and evaluate against this stage play.

Evaluation of the First Agile Manifesto Principle

The first Agile manifesto principle recommends “individuals and interactions over processes and tools.”  While following the audition, the characters were formed, several self-organized teams evolved that took on preparing specific artifacts. While marketing team operated separately from the teams that designed the costumes, prepared the ship, palanquin, backdrop, pillars, and boats, every team led communicated updates through the distribution group, on specific phone conferences, and provided incremental updates. So much was the focus on the individuals and interactions that when one member felt challenged by a work schedule, business trip, or a family emergency, there were so many willing and helpful members that came to assistance. Every team meeting ended up with a summary of the next action items following the same basic principles of what progress has happened, what progress is expected before the next meeting, and what the challenges were trying to create a win-win situation for all.

Evaluation of the Second Agile Manifesto Principle

“Working software over comprehensive documentation, “says the second Agile manifesto principle. While it is true that iterative delivery of working software makes the user experiment with the software mitigating the risk of failure, enhancing speed to market, and satisfying end user experience, can we rethink what software is? 

How many of us will travel on a bridge that is functional for the first 200 yards, but the remaining 100 yards are not yet constructed? How many of us are willing to buy a book that has the first three chapters written but the next 3 chapters are in script review? As you can see, in some cases, the end result has to be a fully functional system or product and not a partially working product. This play required that all the 50 scenes are seamlessly orchestrated and not just partially done. However, the challenges of the working individuals that made up the cast or the stage preparation crew that had overlapping members with cast, required we divide and conquer using iterative releases.

Dividing scenes of the main events in the play, the cast was informed to memorize the lines, rehearse their dialogue, and practice their songs with every weekly iteration and monthly releases over approximately 6 months rehearsing specific scenes in the sequence, making progress in preparing artifacts, checking the costumes, perfecting dance, singing, and fighting sequences of the play. There were even members invited only to provide constructive criticism using index cards presenting the user stories. For instance, one of the index cards read, “As a minister to the King, you should not use too many hand gestures to show your surprise so that the audience knows that you are always composed and thinking of the next scheme.”  Even the venue selection for the 40 individual practice days was so distributed to address geographical challenges to collocate the team to benefit from osmotic communication in that everyone could manage to attend understanding stage movement clues, voice projections under different audio systems, as well as including phone rehearsals to perfect dialogue delivery to combat.

Agile does not say “no documentation” but only “comprehensive documentation.” But the extent of required documentation is left to the individuals in the team. While there was no specific documentation created on how to assemble the palanquin or the shipwreck scenario, there was a substantial documentation created with more than 150 light clues on what area of the stage had spotlight, when there was colored light, when the light flashed to add special effects, etc.  Similarly, there was documentation on the backstage collaboration as stage, scene, and individual props moved seamlessly through worksheets identifying who moved and removed properties to the stage, where they moved, how they moved, and communication protocols to the custodian that gave the cues to the light crew sitting far from the stage.

Evaluation of the Third Agile Manifesto Principle

Agile manifesto values customer collaboration over contract negotiation. Again, real life scenarios such as these stage plays challenge the common thinking of who the customer is.  In business parlance, the customer is the one that pays for the product or service and is the reason why the company is in business. Extending the same terminology would mean the audience that came to see the show or the sponsors that supported the show were the customers. But this stage play extended the notion of customer far higher, such as the following instead of going back to “what you are supposed to have done” contracts based on the rehearsal.

1. A character is a customer when talking/interfacing with another character. So, even when the lines and body language were rehearsed, the team didn’t wait for the cue words that went missing but filled and moved on.
2. The light crew was a customer to the character on stage and when the character in the spur of the moment was on the right marked spot to deliver, the light crew attempted to refocus the light.
3. The cast themselves were customers to the stage crew that required the individual properties to be returned to them for reuse in other scenes. However, when one member missed it on stage or left it on different section of the stage, the backstage crew or the experienced cast members accommodated to keep the show moving without backlog.
4. The self-organized team was so focused on the goals that lines of who was the director/facilitator (product owner) or who was the process checker (scrum master/coach) never needed to surface. So tightly integrated the team was that they even altered their international and other business trips to attend rehearsals, participated in phone rehearsals from taxis, cabs, and hotels during their business trips. The “How may I help?” message and motivation support was so evident among the cast, crew, organizers, and volunteers.

Evaluation of the Fourth Agile Manifesto Principle

Finally, Agile recommends responding to change over following a plan. Although Agile may promote this value statement, this value proposition is emanating from common misconception of traditional project managers that think, “Plan the work and work the plan.” Fundamentally, such purist project managers are those that came to the profession accidentally thinking that working the Microsoft Project plan and being a task master is all that this Project Management means. Contrary to this belief, experienced project managers whether they follow Agile or Waterfall, know that no project goes by the tasks laid out in the work breakdown structure (WBS) of the project plan exactly. If they do, why is fast tracking and crashing approaches exist? 

1. In the stage play, several “gotcha” moments existed. A few examples include the following that emphasize how the stage and crew adopted to change instead of reacting to we should stick to the plan. People that failed to project their voice or speak closer to the microphone got directions from the crew or other supporting cast on stage using body language to direct them to speak louder.
2. Microphones that did not pick the voice adequately from where the throne was located requiring the cast to adjust their movements requiring them to “be in the act” walking closer to the microphones.
3. Using incorrect clues from the stage coordinator to the light crew that started the scene prior to the backdrop swap was completed requiring to readjust the plan as the volunteers got stuck behind and could not be readily available for the next stage transition.
4. Realigning the position of the location of the palanquin and using a different spotlight from the originally approved light sequence when the microphone needs challenged the available moving space for the cast.
5. Altering the movement of the boat movement sequence requires using the entire stage area differently.

Summary

In a nutshell, this stage play is one of the several testimonials that Agility should be in one’s mind first. Agile Manifesto might have started as guiding principles of software development, but its application is not limited to the software development projects.  It is important to understand that everything Agile is subjective and not definitive. This is sine qua non of Agile Project Management. The goal of the iterations or releases are incrementally building progress towards the end goal and the role of the product owner or scrum master is to be authentic in their leadership so that the group buys into the goal becoming a self-organized team. Then, the teams don’t just break a leg! They make history.

References

Manifesto for Agile software development (n.d.). Retrieved May 11, 2013, from http://agilemanifesto.org/

Ponniyin Selvan (n.d.) Retrieved May 13, 2013, from Wikipedia http://en.wikipedia.org/wiki/Ponniyin_Selvan

Agile's Amigo: Process

Stuck in flight delays at the Airport in the last few days, I was sitting at the Gate near the corner of a terminal where I could see through the glass windows the crew that was using the back doors along with the customer service representatives answering the stranded passengers and interacting with the flight crew for boarding preparation. Simultaneously, maintenance crew was inspecting the plane, another group loading the baggage, and yet another group fueling the plane. None of these various groups were visibly communicating among each other at the same time but the whole flow seems so orchestrated. If getting the plane to fly were to be considered as an agile project, then, the tasks associated with checks and balances is so much grounded in process which made me reflect on some comments by a few agile practitioners that there is no value in process documentation.

It is true that Agile Manifesto associates a higher value to “Individuals and interaction” over “processes and tools” and “Working software” over “comprehensive documentation.”  But does Agile truly suggest not having any process to follow or ignore writing any documentation? Let us challenge the agile purists then why is Agile so heavy requiring a process to capture user stories to have some minimum qualifications emphasizing the INVEST principle and backlog entries to follow a DEEP property? Why the developer can’t be left to interpret what should be developed instead of requiring to also understanding how it should be tested?  One may then associate that such silo-ed thinking may lead to failures from waterfall to repeat requiring collaborating using the daily sprint and using the agile dashboards for communication.  In that case, let us reflect further.

1. If projects are successful because of people, then, let us also accept that not all people absorb and consume information at the same pace even in a self-organized team – requiring at least some level of process enforcement such as the same repeated questions used to uproot challenges in a daily sprint. Isn’t this some level of process?
2. Even from a pure engineering and development standpoint, then, why is Agile putting such an emphasis on Refactoring going down to the level of documenting specific smells (Agile terminology indicating a symptom of a problem) collapsing classes to simplify object inheritance design, long parameter list, and even recommendations of how much should be in a specific try/catch block? Isn’t this substantial documentation of processes to be used in agile projects?

Most of the contributors to the agile manifesto came from a strong technical background with a focus on developing IT projects. The logical breakdown of thought process is inherent in the IT discipline. Yet, these practitioners carefully drafted the four manifesto statements where processes, tools, comprehensive documentation, contract negotiation, and following a plan were not considered effective or essential. To those agile practitioners avoiding creating documentation or valuing following a process, let us emphasize that Process is the Agile’s Amigos! 

Agile – Is it a Panacea or a Placebo?

It is true that the fundamental twelve principles of Agile Manifesto (n.d.) have helped many projects succeed in organizations. These results are evident in the increasing 61% of agile practitioners promoting the adoption of Agile in organizations, as noted by the 7^th annual state of agile development survey conducted by Version One. But, several agile purists focus on some of the buzzwords, such as the Test Automation, making it as though Agile is the cure-all for all business problems.

Those in the technical world may understand the famous statement, “Not all business problems are nails to use the same hammer as the tool,” when common object request broker architecture (CORBA) was initiated to introduce by Object Management Group (OMG) the communication between software components regardless of the underlying language used to develop them. However, it is interesting that some agile practitioners are inclining towards test automation as a cure-all (panacea) treating all test cases alike.

Testing requires two basic requirements namely verification and validation. Verification is the process of evaluating test cases, test scripts, requirements or user stories to ensure that the process of testing is going to ensure that the required functionality is present to meet the user requirements. The focus of verification is on the process and is therefore an improvement process oriented towards assuring quality (QA). But validating is the ongoing approach to testing the software with the goal of identifying defects. These defects could be traced to the faulty code, inaccurate design, incomplete or ambiguous requirements, misinterpretation of the requirements, or a combination of these factors. Validating therefore aims at controlling quality (QC).

So, test automation can help in the validation to ensure that every incremental build is tested for the new features but also for the previous features. It is therefore not a placebo but is not a panacea for all business problems. Depending upon the unique business requirements, some requiring can’t be easily automated even if technology can allow it. For instance, testing the human interfacing with the interactive voice response (IVR) at various points in the call flow to check for the disposition code, checking for the line breaks in the email, or the accidental mix up of Far Eastern Asian Language characters because languages such as the Chinese, Japanese, and Korean share a common base do benefit from manual testing.

It is therefore important to evaluate what is the business need in test automation and identify areas that can lead to efficiency gain. Redman and Nielsen (2013) very nicely paraphrased Deming suggesting to carefully select the right process to automate explaining “… automating a process that produces junk just allows you to produce more junk faster". Deming might have inferred this long before the agile was conceived but some golden principles do stand the test of time.

References

Principles behind the Agile Manifesto (n.d.). Retrieved February 13, 2013, from https://agilemanifesto.org/principles.html

Redman, T.C., & Nielsen, D. (2013). Computerization in Health Care Demands High Data Standards. Harvard Business Review. Retrieved February 28, 2013, from http://blogs.hbr.org/cs/2013/02/computerization_in_health_care.html