How Is Emergent Architecture Handled in Scrum?

Scrum embraces the Agile principle of emergent architecture and design. Architectural needs emerge due to functional and non- functional requirements. Certain nonfunctional requirements like security, deployment platforms, compliance, and scalability are often of very high value and ordered high in the Product Backlog. Usually some parts of each of those nonfunctional requirements are required for an initial release of a minimum viable product.Business-facing functionality (i.e., functional requirements) also drives architectural and design needs as well. In Scrum, each Sprint serves to build at least one piece of business-facing functionality that has at least some tiny amount of value. So as we evolve the system, we build only enough architecture and design to support the functional and nonfunctional requirements that we are focusing on for that Sprint.

Important: In every Sprint at a minimum we have to build at least one piece of that business-facing functionality, regardless of how many nonfunctional requirements and architecture we are also focusing on.

Then with every subsequent Sprint, more and more of the architecture and design emerges in response to more and more high-ordered requirements. The purpose of this is to build architecture and design only in response to the highest-valued requirements at the top of the Product Backlog.

 

An example of how Architecture is handled in Scrum.

Emergent Architecture

Emergent Architecture

In the example shown in the chart, in Sprint 1 the majority of the work done by the Scrum Team is on architecture/infra- structure; however, enough business-facing valuable functionality is still released by the team to deliver value and validate the current architecture work. As the team progresses further Sprint over Sprint, the architectural needs decrease, and the value-driven business functionality delivered increases.

The Development Team also ensures good architecture by ensuring a set of guiding architectural principles that every Development Team member understands and follows while writing code. In addition, architecture is an ongoing discussion in the Development Team focusing on implementing current Sprint Backlog items.

This is one of the topics from my book – Scrum Insights For Practitioners: The Scrum Guide Companion“. Happy reading!

You can read more about Emergent Architecture and Design here.

Book: “Scrum Insights For Practitioners”

I am pleased to announce my new book — “Scrum Insights for Practitioners: The Scrum Guide Companion”. Thank you all for your support and help.


The Scrum Guide
holds the bare and essential rules of Scrum. It provides sufficient information to understand Scrum but leaves much open for interpretation by readers and practitioners. When individuals and organizations follow The Scrum Guide blindly, without understanding the real, deep essence of Scrum—the principles and values underpinning the framework—they likely will fail to reap all the benefits Scrum has to offer.

Scrum Insights for Practitioners fills in some gaps in the understanding of Scrum for individuals or organizations practicing Scrum. This book can be thought of as a companion to The Scrum Guide. I encourage readers to first read The Scrum Guide if you are new to Scrum before reading this book, as this will help you reap the maximum benefits.

Scrum Insights for Practitioners is a perfect companion to The Scrum Guide that helps the practitioners master the Scrum framework by gaining in-depth practical insights and helps answer questions such as these:

  • What are some common myths, mysteries, and misconceptions of Scrum?
  • The Scrum Guide recommends three to nine members in a Development Team, but we have fifteen members. Is this Scrum?
  • Can you share some tactics to do effective Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and Product Backlog Refinement?
  • My designation is development manager. Does this mean I have no role in Scrum?
  • How is Scrum Empirical?
  • Can Scrum Master and Product Owner be the same person?
  • We don’t have a Scrum Master. Are we still practicing Scrum?
  • What does Self-Organization really mean?
  • How does Scrum embrace the four values and twelve principles of the Agile Manifesto?
  • Please share a case study on Scrum based product development?

Recommendations for the book from the Scrum champions

Take advantage of Hiren’s vast experience and avoid making the common errors people make as they begin their journey. This book contains a wealth of practical information that will be useful to readers as they work to implement the basic theory found in The Scrum GuideSteve Porter, team member, Scrum.org

In his book Scrum Insights for Practitioners, Hiren has extended the core rules of The Scrum Guide with practices he has found useful. Hiren answers questions regarding Scrum that potentially remain unanswered even after one reads The Scrum Guide. Hiren dismantles common misconceptions about Scrum, regardless of the source of such misconceptions. Hiren elaborates on basic information provided in The Scrum Guide, as well as on the principles underlying ScrumGunther Verheyen, Author of “Scrum — A Pocket Guide, a Smart Travel Companion”

Hiren Doshi has written a fine companion to The Scrum Guide, filling in some of the intentional gaps left in the Scrum framework. Using this companion along with The Scrum Guide will undoubtedly improve the outlook for those teams that internalize its teachings.”Charles Bradley, ScrumCrazy.com

This book will help you understand the nuances of Scrum. It takes a very practical approach toward implementing Scrum without compromising on its values and principles. A useful and handy reference for Scrum practitioners!—Gopinath R, Agile coach and practitioner

Currently the book is available as a physical copy on Amazon. The Kindle version to follow shortly.

I sincerely hope you find great value in each and every page of the book.

Enjoy Reading. Happy Scrumming.

Myths, Misconceptions & Mysteries Of Product Ownership

Here’s what the Scrum Guide says about the Product Owner Role:
“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

Who is an effective Product Owner in Scrum? Is (S)He a requirements typist, user story writer, business analyst, domain expert, maybe all of the above? What are some effective practices of Product Ownership? What are the biggest myths and misconceptions around Product Ownership?

Five of the most respected Scrum.org PSPO Trainers – Ralph Jocham, Mark Noneman, Erik Weber, Hiren Doshi, and Simon Reindl talk and answer questions on Product Ownership myths, misconceptions and mysteries of Product Ownership.

Feedback on the Professional Scrum Foundations workshop

This video captures the feedback from the students on the Professional Scrum Foundation workshop facilitated in India. The students share their learnings on how writing granular user stories, story splitting, defining clear Scrum roles helps with agility. They talk about values and principles like self-organization, empowerment, Courage and Respect needed to embrace Agility. They also talk about the interactive and intensive, hands-on and powerpoint free facilitation of this PSF workshop.

A scaled scrum tactic – Team of Teams, A real life example

A program team of over 40 people decided to move to Agile from their traditional development practices. The program was old and had been in existence for over 6 years. In these 6 years they had released multiple versions of their software product to their customers. In the rush to satisfy the customers they had ignored the basic hygiene of following the good engineering best practices. So, along with their move to Agile they had also inherited a considerably poorly maintained legacy code. There was tight coupling between the various software components in the entire system; The majority of  the code files had 10000+ lines of code with plenty of code duplication; there was poor technical documentation on how the overall system interacted; the entire testing effort was manual. There were certain components which when modified, in most instances, introduced regressions in the existing system.  Even though the teams spent significant time testing the entire end-to-end system, the overall confidence on the quality of the deliverable was considerably low.

The program formed 4 cross-functional Scrum Teams and started sprinting. The dysfunctions from the poorly maintained legacy code started surfacing and becoming more evident.The teams struggled to meet their planned sprint forecast. The development team’s time spent testing the new features was exponentially higher than it took to build those features. In addition, most of the times the development teams kept busy fixing unplanned production defects to maintain the business continuity. The deliveries of new business features were at an all time low which made the sponsors very anxious. The scrum teams collaborated, brainstormed and came to a common conclusion that to accelerate product delivery, one of the first steps was to reduce the manual test effort spent by the development teams. They decided to write end-to-end automated service level tests to cut down the time teams spent on manual testing as well as to gain enough confidence in their deliveries. The product owner helped by ordering the PBIs for the service level automated tests higher in the product backlog. The skill-sets required to develop the service level tests were spread across multiple scrum teams. Something different had to be thought of to overcome the above challenge without having a major impact on the business continuity. A new scaled scrum tactic of “Team of Teams” was introduced: “Team of Teams” is a concept where members with the right skill-set from the existing scrum teams participate to form a new Scrum team for a short duration of a sprint or 2 to solve a very focused problem. The 4 Scrum Teams self-organized and quickly identified 2 development engineers from each team with the correct skill-set to participate in the new “Team of Teams”.

One of the Scrum Masters from the existing teams volunteered to help with Scrum Master duties for the newly formed Scrum team. The new “Team of Teams” decided to operate in “Boot Camp” mode and they co-located themselves in a conference room to allow maximum collaboration. In the first few days of the sprint, the team carved out a homegrown test framework and added a couple of end-to-end tests to validate the framework. A quick review of the framework with the original 4 scrum teams and the Product owner validated their hypothesis. The newly formed team of teams worked through their sprint backlog and carved out 17 rich test scenarios in that sprint. The “Team of Teams” had accomplished their mission of writing sufficient automated test scenarios to reduce the manual testing effort thereby accelerating the product delivery. The team members from the newly formed team of teams then returned back to their original scrum team where they continued to build additional test scenarios. Having led many Agile adoptions across multiple organizations, I have found scaling tactic like “team of teams” to be very helpful when a very focused problem has to be addressed.  The “Team of Teams” tactic has also been explored for strategizing the product vision and the product backlog refinement with multiple scrum teams and overall the outcome has been quite rewarding. I would be happy to hear some scaling tactics you have used and learn from your experiences.

Is agility fueling organizations towards profitability?

Let me begin this blog by relating one of my travelogue experiences. A known taxi driver drives me in his car to the Mumbai airport every week from the last 4 years. The car is about 8 years old, poorly maintained, and has tugged a good more than 300000+ kilometers; has by all means attained end of life, good enough to be dumped, and reap benefits from its scrap. As an enduring passenger, I have been containing the noisy tractor-like ride in his car due to my acquaintance with him and also believing his long false promise of a new car on its way to replace this one!

Week-on-week he comes with the same car and asks me if I noticed any evident difference in terms of travel experience. He would spend good amount of money replacing the old parts (like the tires, cars’ engine, AC, etc.) with better ones, beautifying it by a coat of varnish, etc.; the expenditure now almost exceeding the price of purchasing a 3-year-old second hand car. I honestly said a big NO each time he asked me and also wondered why he was investing on this old car when a new car according to him was arriving in the next 3 months!! This fetish behavior of patching the old car in anticipation of some miracle resulted in the loss of many good loyal customers (as they were fed up of the continued bad bumpy ride with no respite in sight in the form of a new car).

During one of my recent rough ride in the taxi, I realized how well this experience was analogous to what many organizations undergo during their agile journey. They have every agile practice in place; right mindset, best practices, roles/ceremonies/artifacts well defined coupled with communication, motivation, and empowerment. Even with such a robust agile framework, the teams/organizations lack agility to adapt to the changing customer requirements and deliver in a fast paced manner. Although in reality, organizations want to go fast (like any new car) by adopting agile but unfortunately are stuck with poorly maintained legacy codebase (like the old taxi). Any amount of replacement, beautification, superficial modification, or adopting new methodology/technique without addressing the deep-rooted problems might temporarily mask the real problem thereby breaking ‘transparency’, one of the 3 legs of empiricism (for scrum to be effective, each of these 3 pillars – transparency, inspection, and adaptation must stand and be supported).

When such projects are assessed, in all probability the hidden truth is that the organizations carry a herculean technical debt in terms of complicated and poorly maintained legacy codebase (just like the old car) with little or no attention to the engineering best practices, poor feedback cycles, no automation of unit./integration/regression, poor re-factoring and code reviews, etc. Based on the assessment findings, organizations need to perform a cost-benefit analysis and decide whether it makes sense to fuel such projects and take appropriate corrective actions immediately rather than wait for some magic to happen overnight in an organization/product by just adopting agile. If not, (like the taxi driver) organizations will fail to deliver/meet customer expectations, not be profitable, and loose out longstanding clients.

Therefore, for organizations in their attempt to keep pace with the competitive world it is not just enough to adopt agile methodology but should imbibe agility in their DNA. Varnishing an old car may give it a new look but the driving experience will remain the same; the same applies to organizations as well. In most cases, change/expected results may not be visible by just refactoring in bits and pieces (replacing the defective parts) but it may call for a complete eradication of the existing system (significant remarkable/dramatic one which would be a winning selling pitch for the organization; in the car analogy it is like buying a new car) and re-designing/re-writing the software to bring in a new vibrant spectrum.

Upon this cleanup and novel thought it is now time to think how to drive this concept (new car) effectively and efficiently! Adopting the rich agile ethodology along with adhering to solid engineering practices at this juncture would act as a fuel to propel the team/project/product/organization, accelerate, and drive towards success!

With the legacy issues addressed and best engineering techniques embraced, agile adoption certainly triggers agility and benefits the organization by delivering fast-paced, feature-rich, competitive, and user-beneficial products of significant business value!

The Power of Anonymous Retrospectives

The Scrum values – Openness, Commitment, Focus, Respect and Courage are the foundation for the behavior and practices in Scrum. It’s difficult for organizations to adhere to these values from the onset of their Agile journey. Agility is about behavior and cultural changes and the values listed can’t be demanded, they have to be earned by creating transparency and is a journey that never ends.

While coaching Agile teams over the years, I have learned that no matter how open and transparent the organization is, there will be some individuals that won’t openly speak up. They are mostly introverts and have a phobia of public speaking. They will limit their interaction to a bare minimum. In some organizations engineers carry the management fear. They feel like they are being observed and anything and everything they say will reflect in their yearly performance appraisal and they clamp up. In either of these situations or situations similar to these, the Anonymous Retrospective helps get the real pulse on the floor. It helps all the participants open up and talk about what they really feel deep within about the organization, the culture, the people, the leadership, the technology, the motivation factor, etc.

So what is Anonymous Retrospective? As the name suggests, all data collected is completely anonymous. The first rule of the Anonymous Retrospective is the data collected has to be truly anonymous and there should be no attempt to tie the same to any individual – either through the language used to describe it or with an handwriting match. What I normally do is I put an empty container in the middle of the room and  give each participant a bunch of Post-its. I ask them to jot down their thoughts on what is working well and the areas that need improvement. I emphasize to the participants that this is a Anonymous Retrospective and encourage them to share their thoughts without having an iota of worry. I then ask them to fold the post-its and put it in the empty container. I normally time box this to around 25 to 30 minutes.

Once everyone is done, I get the container with the post-its and give it a good mix. Then I appoint someone neutral to take notes on their laptop and help me with basic categorization. I pick each note and try to read it as verbatim as possible, except for certain cases where there are personal attacks. I read them one at a time in front of the entire room, the person taking the notes captures it, and then I tear the post-it in front of all the participants and put it in the trash can to maintain confidentiality. This is what I mean by “Anonymous”.

Anonymous Retrospective will generate plenty of data which has to be validated for its accuracy. Once all the data points are collected, work with the participants in the room to finalize the categorize the data, and generate information by connecting data in each category together.  Following this put an action plan together to address each category. Most likely you will need multiple sessions to do this… but remember you now have some solid facts with which you can incrementally introduce improvements. This is what the power of Anonymous Retrospective is!

I am happy to hear your thoughts.

Sachin Tendulkar – An Agile Case Study

Yesterday Sachin Tendulkar, my Hero, a cricketing legend, the GOD of cricket called his retirement after he plays his 200th Test Match on the Indian soil.

This was indeed an emotional moment for me as we not only share the same birth year but plenty of good memories and achievements in my career are tied to Sachin’s achievements. It will be a shame on my part if I don’t blog about him and pay respect by relating the same to the “Agile Values and Principles” he has demonstrated during his entire cricketing career of 24 years.

Sachin, as a child dreamed of playing Cricket for India and he fulfilled his dream by passionately living and breathing cricket everyday for 24 years of his life – and the records he has achieved over his career speak for themselves.

He always leads by example be it batting, bowling or fielding and keeps laser sharp focus on the goal every time he is on the field.

He is not only a Self Motivated individual himself, but also a motivation for millions of cricket fans around the world.

Sachin is a mentor and coach to so many young Indian cricketers, of which some were not even born when he debuted his cricketing career at the age of 16.

One can’t find a better example of regular inspection & adaption than Sachin. Cricket as a game has changed a lot in 24 years – from Test cricket (5 days), to one day (50 overs), to T20 and Sachin has not just kept abreast  in all formats of cricket, but also excelled in each format which is no small feat. He always planned his innings, but at the same time adapted and responded to changes as the situation demanded.

As for the impediments,  Tendulkar has been stricken by so many injuries during his career spanning more than two decades. In addition to the injuries, the media and general masses (the stakeholders)  had also given him so much negative flack at times. But time and again he has come back with a bang, silencing his critics and delivering to their expectations. He just knows how to move forward in the face of impediments.

Sachin Tendulkar surely had bad years (sprints) in his career. But what made him stand out from the rest is the realization that there is a certain problem and honestly working on it and then coming back stronger every time.

Now, isn’t this what Agile is all about?

Sachin, you will always be missed on the field (though, we get 2 more opportunities to watch you in action).
However, the legacy you have created will live for generations to come! 

Ran my first Half Marathon the Agile way

The Worli Sea Link

On January 20th 2013, I ran and successfully completed my first Standard Chartered Half Marathon in the beautiful city of Mumbai in an Agile way. What an awesome experience it was. 

My skill level with running: Novice,  I had put around 90 km of  a total run in a period of 3 months during training. Just for comparison, average runners put around 100 to 150 km in a month. 

The most I had run at one go was 10 km in the time period of 1 hour and 20 minutes.

 Motivation: To help the Udaan foundation raise funds to support 2 under privileged students for a year.

Release Planning:

Release Goal: Run 21.097 Kilometers in under 3 hours, which is the qualification time.

Approx Velocity (Based on past experience): 7.5 kms / hour.

Total Sprints needed: 21 / 8  =  Approx 3 sprints of 1 hour each.

 

Sprint 1: The amazing Mumbai weather, the Worli Sea Link being the start location, and a total of over 16,000 participants in the 1/2 Marathon, created an atmosphere that one has to experience and can’t be described. All this was motivation enough for me to build a constant pace of about 7 minutes and 30 sec per km for the first hour. The stakeholder (that’s me:-) ) was very happy with the outcome of Sprint 1 and decided to continue with the release. The Retrospective revealed a improvement area of slowing the pace down a bit as certain impediments around fatigue and pain had been logged.
The velocity achieved by end of sprint 1 was 8 km. 

 

 

Sprint 2: Using yesterday’s weather as a forecast for velocity and keeping the retrospective improvements in mind I planned sprint 2 with a goal of achieving 7 km instead of 8 km in the next hour. I nicely built a pace of 8 minutes and 15 sec per km. The face-to-face cheering of the crowd, the loud music by DJ’s throughout the route, and the cause of the run lifted my spirit and kept me motivated throughout sprint 2. By the end of sprint 2, I had completed another 7 km and had achieved a total run of 15 km. The product backlog showed 6 km of a run remained for the minimum marketable functionality to there by achieve the release goal. The stakeholder was again very happy with the achievements and decided to continue with the release. The retrospective did not reveal any major improvement area other than suggesting to slowing down the pace even further. 

 

Champions with Disability

Sprint 3: With 15 km of a run complete and only 6 km remaining, the stage was set correctly for the final sprint. However a little after 1 km in the final sprint there were 2 new impediments – cramping and thoughts of quitting the race. To manage the first impediment, I switched from run to walk and started hydrating myself every 100 meters. The exhaustion was causing my second impediment to grow stronger and stronger putting the entire release at a risk. As I was battling these thoughts of quitting the race,  I passed by the “Champions with Disability” on the other side of the road. The smiles on the faces of these participants with special needs and their attendants was  just the motivation I needed for me to cruise through the remainder of the race. 

And I completed my first half marathon in 2 hours 49 minutes and 42 seconds!

1 2
×
×