Category Archives: LeSS

Sept 13 -14 | 3rd Global LeSS Conference | NYC


Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.


Conference Space and Our People
Experience Report of Guest-Blogger Ram Srinivasan

Though I have been associated with the Large Scale scrum (LeSS) community for about five years (though the “community” did not exist,  I can think of my association with like minded folks) this is my first LeSS conference. While I used to attend a lot of conferences in the past, I have started focusing more on deep learning (by attending focused workshops) than focusing on conferences. But this year, I had to make an exception for the LeSS conference Why (a) it was the first LeSS conference in North America  (b) It was not very far and (c) I was thinking that I might meet some of the smartest people in the LeSS community whom I may not meet otherwise and (d) I have heard that it is a “team based” conference (unlike other conferences where you are on your own) and I wanted to find out what the heck it was. I was not disappointed.

The venue itself was very different from the conventional Agile conferences  – not a hotel. That definitely caught my attention !! I was pleasantly suprirsed to see both Howard Sublet (the new Chief Product Owner from Scrum Alliance) and Eric Engelmann  (the Chairman of the Board of Director of Scrum Alliance ).  Howard and I had good discussions on LeSS, Scrum Alliance, the marketplace, and scaling
Some sessions that I attended and major takeaways:
  • Day 1 morning keynote –  Nokia LTE  implementation  – Takeaway – Yes, you can do Scrum with more than 5000 engineers
  • Day 2 keynote  by Craig Larman. I always find Craig’s thinking fascinating and learnt quite a few interesting facts about cognitive biases (and strategies to overcome them).
  • LeSS Games – component team and feature team simulation lead by Pierluigi Pugliese – very interesting simulation – I used a variation of this in my CSM class past weekend and people liked it. I hope to write about sometime, in the coming days
  • LeSS roles exercise by Michael James –  I have always been a fan of MJ. Very interesting exercise which reinforces the concept of LeSS roles
  • TDD in a flip chart – Guess I was there again, with MJ. Well, just learned that you do not need a computer to learn about TDD.
  • An open space session with Howard Sublett on LeSS and Scrum Alliance partnership (yours truly was the scribe) – Lot of interesting discussions on market, strategy, and positioning of the LeSS brand.  I personally got some insights from Rafael Sabbagh and Viktor Grgic.
Two days was short !! Time flew away.  It was a great experience !! And  I wish we could have a North American LeSS conference every year !!

Experience Report of Guest-Blogger Mark Uijen de Kleijn

I’ve attended the 2018 LeSS Conference- my first – in the Angela Orensanz Center in New York. I was really inspired by the many great speakers, experiments and experiences and was glad I could help Jurgen de Smet by his workshop on Management 3.0 practices that can complement LeSS with experiments.

A couple of notes on the Conference; it has been the first Conference I attended in years where I actually learned a lot, either from the many speakers, experiments and experiences, but from my ‘team’ as well. As the LeSS Conference is a team-based conference, we reflected on the content and our insights during the Conference, which accelerated my learnings.

As I use many games and practices in organizations or courses, I’ve seen several great new games that I can use myself. The ‘building agile structures’ game of Tomasz Wykowski and Justyna Wykowska was the most outstanding game for me, because it makes the differences between component and feature teams very clear when scaling work, and I will use this for sure in the future. The experiences at Nokia by Tero Peltola were very inspiring and especially the focus on the competences (of everybody) and technical excellence I will take with me.Thoughts that will stick with me the most after the conference: the focus on technical excellence (including e.g. automation, code quality, engineering practices etc.) and the importance of the structure of the organization, following Larman’s fifth law ‘Culture follows structure’. The latter I’m already familiar with, but needs to be reprioritized in my mind again. The former will be my main learning goal the coming period and I will need to dust off my former experiences.

Interesting quote to think about, by Bas Vodde: ‘we should maximize dependencies between teams’ (to increase collaboration between teams).


Games and Team Activities

LeSS Graphic Art


My partner in crime (Ari Tikka) and me  – Presenting on Coaching

Click here to download presentation: Ari’s deck | Gene’s deck.


Personal Memorable Moments


Next LeSS conference (2019) – Munich, Germany

May 30th-June 1st: Certified LeSS Practitioner Course With Craig Larman | NYC

Another LeSS Training (CLP) with Craig Larman is in the CompuBox.  This highly engaging training brought together 35 attendees from all over the globe.  One of the attendees was Chet Hendrikson.  A bit about Chet:
Chet has been involved with Agile Software Development since 1996 and is the first signatory to the Agile Manifesto. Along with his long-time friend and colleague Ron Jeffries, Chet has made the following important contributions to the global agile community:
  • Wrote Extreme Programming Installed (also with Ann Anderson)
    In 2009, developed for Scrum Alliance the Certified Scrum Developer program
  • Taught the first Certified Scrum Developer (CSD) course
  • Have been curating the Scrum Alliance’s Agile Atlas website
  • Created the SA’s official Scrum description, Core Scrum
  • Speak at conferences, bringing an interesting mix of humor and deep knowledge, and the odd cat picture.

This is what Chet had to say about the course:

“Chet Went to Craig’s LeSS Course”

Many years ago, I wrote an article entitled “Inside every 100-person project is a 10-person project trying to get out.”  That pretty much sums up my feelings about Agile at scale.

My interests have always been with the programmers and their safety and not with how to “Agilize” the organization.  Some of this was a reaction to the failure of most Agile transformations.
But, as someone deeply rooted in the Agile movement, I feel it is important to pay some attention to the “scaling” end of things.  A couple of years ago,  Ron Jeffries and I took (most) of the four-day Implementing SAFe course.  You can read about that at https://ronjeffries.com/xprog/articles/safe-good-but-not-good-enough/.
I have also been paying attention to Craig Larman and Bas Vodde’s Large Scale Scrum (Less).  So, when I saw that Craig was teaching a LeSS Practitioner course in New York on a week I was not working, I signed up.
There were a couple of reasons for me to take some time away from my wife and cats to do this.  First, after having read the LeSS books, I wanted to learn more.  And, secondly, I have always enjoyed my interactions with Craig and wanted to spend some more time with him.
The course is three full days, 8:30 to 6:00, and involves a great deal of hands on work.  And, I do mean work.
Craigs starts the class by saying that “you won’t successfully be able to return to your workplace and ‘give a summary’ of your insights; it is futile & won’t be understood.”
He is right about this.  But I will try and give you my impressions of the course.
One of the key takeaways from the course is something I already believed, which is don’t scale.  Do everything possible to build your product with one time.  If that is not enough, find ways of descaling your problem.  Only if that fails take the steps required to turn your organization into one that can build large products with Scrum.  Doing this effectively will require many changes.  Most of which are about removing management and simplifying information flows.

Craig’s organizing principle for the course is that in order to successfully use these ideas,  you must own them.  Having an instructor, no matter how good they are, no matter the depth of their experience, teach you something is no where as good as discovering the answers yourself.  To this end, we spent most the the course learning and practicing organizational modeling to derive the practices and structures that align with our goals.

In the course, our goals where to create a learning organization that has the ability to “turn on a dime for a dime.”  You may have other goals, but these tools will help better align with them no matter what they are.
Only on the afternoon of the last day did we turn to a full discussion of LeSS.  This was very insightful and was a fitting way to close out the course.
If you are interested in Scrum at scale, I highly recommend  this course.  If you are interested in bringing your organization into sync with its goals, then this is the place to start.

 

Some more Kodak moments from the event are below:






 

 

 

 

 

 

December 6th-8th: Certified LeSS Practitioner Course With Craig Larman | NYC


Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.

More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.

Course Highlights

With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum.  It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework.  On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.

Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner?   Well…

  • LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner.  LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block.  Understanding basic Scrum made understanding of LeSS very easy for everyone.
  • The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like 😉, when coming in.  Everyone in class was an educated customer.  Importantly: there were no attempts to change LeSS (or change training content 😊  of LeSS), to make it better fit conditions of organizations, where people came from.
  • Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.

The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)

One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many).  And it goes as follows:

…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle).  ‘Agile’ won because of the reasons that are described here.  Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible.  We all have to be careful with the meaning of words we use, to avoid this painful irony😉.


Here are some Kodak moments from the event:

10/13 – LESS TALKS: MEETUP – Working LeSS Brings Great Results (Case Study)


Tonight -a  great presentation by Malik Graves-Pryor of Natoma Consulting, as he shared how his company leveraged LeSS to achieve  stunning results, while facing challenges and learning lessons.

Malik’s Summary

At the Thursday October 12, 2017 NYC Large Scale Scrum Meetup, Malik Graves-Pryor shared his company’s LeSS case study, “Web and Mobile Applications Agile Transformation”. He covered the extensive issues the company faced at the beginning ranging from only 1-2 releases a year with hundreds of defects, and how they transformed over the course of several months to an organization that released monthly, and then continuously, with low defects and high customer satisfaction and engagement.

The discussion covered the merger of the Sales and Product Management Pipelines, adoption of technical practices leading to a DevOps-focused culture, how to take the necessary steps to build trust and cooperation within the organization, as well as the road-map they used to iteratively migrate the organization to continuous integration and deployment.

The interactive discussion spanned two hours with attendees raising questions and issues about the case study, as well as correlating them with their own challenges and aspirations.

Presentation deck is available at  Natoma Consulting website for download.

 

Agile Organization, as a Sushi Roll


When we ask an experienced Scrum developer what defines a good User Story, the answer we hear almost immediately is that “…every user story must be INVEST-able…(taken from B. Hartman’s post)”.

When we further elaborate on “INVEST” part, we hear that splitting user stories should be done Vertically (along features), not Horizontally (along components or applications layers).  Why is the latter condition so important? Because when split vertically, and cross-cutting through multiple components, a user story has a much higher chance of representing a potentially shippable product increment (PSPI).  Delivering, UI/UX alone, or business layer alone, or database alone, does not present value to a buying customer.

Frequently, we hear the analogy of a sushi roll, when describing story slicing: “…every User Story must represent thinly sliced sushi roll that provides taste and flavor of multiple layers (caviar, seaweed, rice, tuna, avocado, etc)…


…Now, imagine an organization that is undergoing agile transformation.  Predominantly (statistically), transformation efforts stem from Technology, where agile improvements come in the form of introducing good engineering practices, such CI/CD, TDD, unit testing, test automation, automatic deployments, etc.  But technology alone, is just one layer of an organizational sushi roll.  Sure, just like seaweed alone, it may be tasty enough for starters, but without adding additional flavors, it is not a complete, healthy meal.

Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment.  A slice does not have be too thick. If organizational slice is too thick, it might be too big to “swallow and digest”.  But still, even when sliced thinly, an organization must include enough layers, to be considered as complete meal.

What are some of those layers?  Let’s consider a few:

Business & Operations:  it is imperative to have real customers intimately involved in agile transformation efforts and making them closely aligned with technology partners. This requires identifying and providing a strong support for some key agile roles, such as product owner, stakeholders and SMEs.  Often, this requires organizational realignment and changes to sphere of influence.

HR:  Subjective monetary rewards that are based on individual performance assessments and fueled by invisible internal competition among employees, must be discontinued, in favor of incentives that promote teams’ collective ownership and performance.  An organizational slice that wants to become more agile will have a much higher chance for success if HR policies were genuinely supportive of the initiative of the efforts.

Budgeting & Finance: For agile teams (Scrum, Kanban) that use adaptive planning and iterative development, and continuously have their work re-prioritized by business, it is imperative to have flexible budgets (“flexible spending”).  By unlocking a rigid budget corner of what is known as Project Management Iron Triangle (budget, scope, timeline), technology dramatically increases their chances to do research or conduct new experiments, if an opportunity presents itself (often, unexpectedly).  There is also a higher chance that more Scrum teams would be built out faster, if budgets were flexible and not done as ‘budgets against the wall’ (‘the world ends on December 31st’) – more flexibility to acquire new talent.

Real Estate & Facilities: Having agile teams co-located under the same roof is a huge win: e.g. Scrum team dispersed around the globe is not as good as Scrum team placed on the same floor. (Note: Please, do not confuse a single Scrum team spread thin across multiple locations with multi-site Scrum product development, when many, whole teams are collocated but separated from from peers-teams by geography).

However, putting a team on the same floor is not sufficient.   Interior design must be supportive of team collaboration and dynamics: ‘caves & common’ (read A. Cockburn about XP), information radiation techniques (lots of whiteboard space, flip-charts), breakout areas, extra space to accommodate extended user community during sprint reviews, etc. – is all required.  It is unfortunate but common to see so-called Scrum team members sitting in a long single row, next to each other, spear-headed by a line manager (usually, a window seat), all joining a daily stand-up call by phone (while sitting!) and ‘reporting on status’, while staring at an electronic story board on their respective monitors.  Agile teams don’t want that.


As a summary, please consider the following quote that describes sushi-roll-like organizational design in Large Scale Scrum (LeSS), by C. Larman:

Listen to the Webinar: https://vimeo.com/259108134

LeSS “Construction”: What is it like?


[also, cross-posted on less. works]

Large Scale Scrum (LeSS).  It is the framework for scaling agile development, done by multiple teams, as they work on same product and work for a single Product Owner.   In order to be effective, LeSS requires organizational descaling that means simplification/flattening of organizational design.

What is Organizational Design?  To understand it better, let’s look for analogy in construction industry.  What is required to erect a building? In our analogy, we shall stay simple: bricks (foundation block) and cement (connective material that holds bricks together).

Imagine two buildings: Building A and Building B.

Building A uses brick as its main foundation block.  In fact, when looking at the building’s facade, the most prevalent object, caught by a naked eye, is a brick.  Bricks are positioned next to one another, with just enough cement in-between to glue them strongly together. There is no excess of cement anywhere: the connection layer is very thin/lean.

Architectural design of building A is simple and flexible: the structure is flat (one-story high) and it sits on strong foundation, also made of brick.   Because of its design, architectural adjustments are possible in various sections of the building, independently, with little additional labor.  Due to such modular structure, the building can be expanded laterally, just by adding more bricks to the wall.  Of course, due to its flat structure, the building is also very stable and can withstand a strong wind, flood or an earthquake: practically nothing can be shaken off or washed off the building.

When waste is produced inside the building, it becomes noticeable immediately. Waste disposal is also very simple: it does not require complex chutes or automated waste ‘packaging’ systems.  Waste removal can be mostly done manually, by building residents.  Any necessary supplies (e.g. food, water, furniture, other materials) can be easily delivered to any building area, without the need of advanced technology or mechanics.

Finally, building inspection and maintenance is a very easy process, because of flat structural design: foundation, walls and floor assessment – all can be performed with a naked eye; corrections can be done timely and efficiently.

This is what building A looks like:


Building B is made of a very few bricks and a lot of cement in-between that holds bricks together. In fact, the ratio (by weight) of bricks-to-cement is very low.

Architectural design of building B is rigid. It has many floors, with top floors made primarily of cement.  The building represents a heavy and monolithic structure, and although it also sits on brick foundation, as building A, the bricks are widely spaced with lots of cement in-between.  This means that the overall weight of building B is dangerously high (foundation can crack).  The building’s expansion limit, to accommodate growing occupancy demands, is low: it cannot be easily extended (scaled) horizontally with a couple of extra bricks added to the side, because the bottom brick layer would require multiple horizontal cement layers added on top – to follow the originally intended building design.  If additional cement layers are added on the top of foundational brick layer this will further increase risks of foundation cracking.

Waste disposal is a serious issue for Building B.  While waste can be relatively easy removed from the bottom floor (it is also not in abundance there) and, to some extent, from top floors (by taking it to the roof and using a waste removal chopper 😊), there is a huge amount of waste that gets accumulated at middle floors – and it sits there.  It is extremely challenging to remove this mid-section waste and what building management does from time to time, is ordering for this waste to be moved from one floor area to another (the building is very compartmentalized).  Sometimes, waste gets moved to floors above; sometimes – below.  This creates an illusion of waste removal. But waste remains.

Delivery of supplies and food to Building B occupants is a real challenge, especially if elevators are out of order.  This makes occupants angry and frustrated and sometimes they turn onto each other; become competitors and rivals.

Finally, building inspection and maintenance is a nightmare for Building B.  Many living units are out of compliance with building codes, but violations (and violators) are hard to identify and remove because true facts are well concealed and numbers are gamed by building occupants.

This is what building B looks like:

Large Scale Scrum requires organizational design that is analogous to the construction represented by Building A.


In LeSS:

Team represents the main building block (a brick). Selected team representatives (developers) and mentors-travelers–ensure effective coordination/connection between teams.  There are no additional roles required for coordination.  Cross-team events are minimal (Overall Product Backlog Refinement, Sprint Review, Overall Retrospective).

If product definition widens and more developers are included, another team can be formed and positioned laterally to existing teams – just like a brick.  Should product definition become too wide and the number of required developers exceeds 50-60 people (8 teams), another product area can be identified (new independent module, made of bricks).  Now, LeSS becomes LeSS Huge.  The only additional coordination that would be required in LeSS Huge is between Area Product owners and Overall Product owner – for strategic planning of Potentially Shippable Product Increment (PSPI) at the end of every sprint.  In both, LeSS expansion from 2 to 8 teams, and LeSS Huge expansion beyond 8 teams, there is no need for additional coordination that is different from what is described above (no extra cement needed to keep bricks together).  Also, in LeSS Huge, when one Product Area expands and another one shrinks, moving the whole team from one area to another, does not require expansion or shrinkage of any additional “supportive” organizational layers.

By design, LeSS foundational structure is very lean: flat, fungible and cross-functional.  There is no waste or overhead with roles, responsibilities, events or artifacts.  Everything is very minimalistic.  If any waste is generated in LeSS, it has practically nowhere to hide.

Because there is so much transparency in LeSS, waste is seen immediately.  Any findings of waste or any other required improvements to individual teams or LeSS framework, can be effectively done in Team Retrospective or Overall Retrospective, respectively.  Thanks to its flat organizational structure, LeSS (and LeSS Huge) don’t have to worry about waste removal from additional organizational layers – they [layers] just don’t exist.   There are fewer layers that sit between LeSS teams and LeSS Product Owners and these layers are much thinner.

What happens with LeSS organizational structure during rough times: slow down in business, increased market competition? Arguably, because LeSS is so lean and there is continuous learning, it is much less likely that LeSS people will be displaced. LeSS is also more likely to withstand other types of reorgs and shake-ups because LeSS has very few moving parts, loose pieces or weak links.

Organizational designers that support LeSS think like building architects that want to build strong, reliable, easily-maintainable, low-waste, cost-effective and long-lasting structures!!!

Many thanks to all LeSS Trainers, Coaches and Practitioners building reliable structures 😉.

Signed: ____________The Organizational Building Management 😉

Sprint Length: Who Decides? How? Why?

What is the best Sprint length?  Who decides on Sprint length? Are there any exceptions?  What are some of the most common mistakes people make, when making decisions about Sprint length?

Let’s start from grassroots and answer the following basic question: “What is Sprint main goal?”  And while looking for an answer, let’s refer to the Scrum Guide, where the goal of each sprint is clearly described as “…increment (a.k.a. PSPI = potentially shippable product increment) that must be in usable condition and meeting DoD (Definition of Done)”.  From the Scrum Guide perspective, it is also clear that while being potentially shippable, an increment does not necessarily have to be shipped.  Why is it so? For PSPI to be shipped, it must also represent MMP (Minimal Marketable Product) and the decision about what is marketable comes only from Product Owner and it is based on several factors, including long-term strategy and economics.

(Note: End-of-Sprint deliverable, sometimes, is also referred to as MVP (Minimum Viable Product) and is described well by Roman Pichler here.)

Sprint Length and Release Economics

Speaking of economics, lets recall the relationship between Transaction Costs (Shipping) and Holding Costs, also described in “The Principles of Product Development Flow” by D. Reinertsen.  By analogy, if applied to Scrum product development, ‘batch size’ would represent a volume of PSPI and ‘cost’ would represent all combined efforts, associated with  production deployment (e.g. integration, end-user training, marketing announcements, etc.).

How does this relate to Sprint length?

While each Sprint is supposed to produce PSPI, it is only Product Owner’s decision ,when to release it (MMP), depends on finding a “sweet spot” between the two types of cost: Holding and Transaction, or if spoken, in software development terms, costs of code deprecation/aging and costs of deployment. On the graph above, it is illustrated by the lowest point of Total Cost curve and it is responsibility of Team and Product Owner to determine what it is.

Corollary to having both strategy and economics changing over time, release frequency may change as well.  It would be natural to assume that sprint duration and release frequency are related too.  Indeed, the need to release more frequently may lead to sprint shortening, and vice versa.

Are there any other external factors that may influence Sprint frequency of a single Scrum team?  The most classic example would be Scrum by multiple teams that sprint together (e.g. LeSS, S@S): develop the same product, for the same Product Owner, and share the same a backlog.  While release economics principles would still apply, the situation with scaling may become more complex if multiple teams are tasked to select a shared cadence.  One assumption comes to mind immediately: if multiple teams sprint together (synchronously), then their shared PSPI (overall output) will be more substantial (“voluminous”) than that of a single team, and from a Product Owner’s point of view, may sooner merge the gap between PSPI/MVP and MMP (more about factors influencing Sprint length below).

In other situations, e.g. in non-scaled settings, individual Scrum teams could be dependent on other teams (Scrum, Kanban, Waterfall groups, etc), separate organizational domains or external vendors that operate on their own cadence.  In such cases, product backlog refinement and sprint planning becomes even more challenging.  As a result, sprint length, as well as frequency of scheduled production releases may be impacted.

Who Ultimately Decides on Sprint Length?

Just like any other decision about Scrum team dynamics, the decision on sprint length belongs to a team.  Nobody should be deciding how to structure or manage work, on behalf of people that actually do it.  Neither Product Owner, nor stakeholders, nor management, nor anyone else.  Teams that are new to Scrum may experiment with sprint length at the beginning, while trying to optimize to conditions that are very specific to a team’s dynamics.  The best time to self-assess and decide if sprint length should be changed is during a retrospective, when decisions about process improvements are made; and it is done by majority voting.  Only in rare cases, when a team has a difficulty to reach consensus, ScrumMaster , who owns Scrum process and plays the role of an arbitrator in retrospectives, can step in and help a team make a choice.  This should happen rarely, as frequent lack of consensus might be a sign of deeper team dysfunctions.  Initially, during team formation, and before ScrumMaster is elected, Scrum/Agile coach may help team with sprint length selection.  Mike Cohn describes his personal experience in a similar situation here.

Factors to be considered while selecting Sprint length?

As a rule of thumb, sprint length should not be shorter than 1 week and should not be longer than 4 weeks. If there is a strong reason to make sprints shorter than 1 week (e.g. could be driven by production release frequency requirements), Kanban, instead of Scrum, could be considered, since it offers, on demand and almost instant, release capabilities.  On the other hand, extending sprint length beyond 4 weeks may lead typical challenges of waterfall (sequential work, silos, hand-overs).

Statistically, anywhere between 1 and 4 weeks, a team should be able to establish a steady and healthy cadence to do product development.

Shorter sprints do have certain advantages:

  • More frequent sprint reviews and retrospectives – shorten feedback loops that allow applying improvements to product and process development, respectively.
  • Shorter sprints require lighter sprint planning and, subsequently, reduce the risk of going too deep into a product backlog and selecting items for a sprint that do not meet DoR (Definition of Done) and are not INVEST-able.

Shorter Sprints may also bring some potential challenges:

  • For example, the ratio of time spent on sprint preparation and process management to time spent on actual product development could be high – too much procedural overhead.
  • Additional important prerequisites must be met, before moving teams to shorter sprints. For example, if a sprint becomes too short (e.g. 1-week) and there is no full test automation and no TDD, then a team may have a difficult time, keeping up with testing: after completing a few sprints, as  the amount of code base increases, manual testing will fall behind. As a result too much work may fail DoD by Sprint-end. 

Relationship between Sprint length and Scrum Maturity

It would be reckless to claim that there is a direct cause & effect relationship between sprint length and maturity.   Some research indicates (some was done by Jeff Sutherland) that for as long as a sprint is under 1 month, there is no strong and immediate correlation between sprint length and performance. But anything beyond 4 weeks lowers performance and introduces elements of waterfall dysfunction to a team’s dynamics.

What is, by far, more important than sprint length is sprint length consistency.  While in early stages of sprinting, it is normal for a team to experiment with sprint length, if length “juggling” continues into later sprints or happens ad-hoc, it could be viewed as a sign of deeper problems.  Some teams falsely believe that by periodically extending a sprint they will be able to get more work to Done state.  Thinking more systemically, this is a false assumption, as cadence- and task-switching, especially done by multiple  teams,  can significantly lower overall output.  Further, inconsistent sprint length will lead to difficulty of sprint planning, unstable velocities and unreliable long-term forecasting.

2017 Agile Maine Day Recap

The 2017 Agile Maine Day event is in the books.  Great event organization. Great energizing crowd. Amazing presenters and speakers.

Below are the summaries of two selected presentations, whose themes were mostly relevant to System Thinking and System Design:

Don Macintyre’s topic “Agile Leadership” was about Radical Management (Steve Denning’s teaching) and covered:

  • Shifting focus from making money for shareholders to focus on delighting customers through continuous innovation
  • Managers focusing on controlling individuals to Managers empowering and supporting self-organizing teams
  • Shifting from controlling work with bureaucracy to guiding innovation with priorities
  • Shifting from predominantly valuing efficiency to valuing Continuous Innovation
  • Shifting from top-down command structures to horizontal communication and collaboration

Don also talked about Agile Leadership Mindset and stressed the importance of the following behavioral transitions:

  • From Directing to Coaching
  • From Hiding Failure to Learning from Failure
  • From Telling to Collaborating
  • From Avoiding Blame to Seeing Feedback

Bob Sarni’s – “Radical Collaboration” delivered the following main message: “Organizations cannot compete externally until they can collaborate internally

Bob referenced the book “Corporate Culture and Performance” by John Kotter and James Heskett: Non-enhancing Cultures vs. Enhancing Cultures, alluding to the fact that sometimes the best way to overcome resistance, is to remove resistors.

The following four quadrants of self-discovery were covered:

  • Who we are (Self-mastery):
    • Self-Awareness
    • Self-Esteem
    • Emotional Intelligence
    • Values
  • Interpersonal (Social Intelligence):
    • Communication
    • Trustworthiness
    • Cooperation
    • Rules of Engagement
  • What we Do:
    • Project
    • Product
    • Task
    • Service
  • How We Do it:
    • Systems/Processes
    • Decision Making
    • Structure
    • Policies

Bob also stressed the point that when it comes to going through organizational changes, companies tend to focus on Practices, instead of focusing on underlining Principles and Values. This results in unsustainable, short-term successes only.
Another great quote from Bob’s session: “Business Analysis have their focus on the outer side of business”, mainly focusing on questions of ‘what should we be doing?‘ and ‘how can we do it better, faster and more efficiently’.  It turns out that the inner side of the business is where the greatest opportunity for radical improvement resides”.  The inner side of the business contains the heart and soul of the business.

Finally, Bob talked about Red Zone vs. Green Zone Behaviors (refernicing work of James Tamm)


Bob also described Pink Zone behavior that usually manifests itself by the following actions: Leave, Quit, Hide, Passively Resist, Appease, Give in

(At closing, a kodak moment with Dan Mezick and Bob Sarni)

 

Agile Flyer – 04-09-2017

 



 

Public Announcement:
Scrum Alliance® Announces Partnership with LeSS Company

 

Denver, CO,— SCRUM ALLIANCE® – The news are finally out and public: On 4/7/2017, Scrum Alliance interim CEO Lisa Hershman, has announced that Scrum Alliance,
most established and influential professional membership organization and certifying body in the Agile community,entered in partnership with LeSS Company to support widespread adoption of Large-Scale Scrum (LeSS).

-Read the entire press release…

Join your local LeSS communities today.
(LeSS NYC)

Applying LeSS Thinking to Basic Scrum
“LeSS Hexagon of Values”

As per Scrum Guide, “…Scrum is a framework for developing and sustaining complex products…
It [Scrum] is lightweight, easy to understand and difficult to master”.
The guide talks about basic Scrum, or Scrum by one cross-functional team that works for only one Product Owner, on one single product.
The guide also mentions situations when multiple Scrum teams must work on the same product backlog and share the same Definition of Done (DoD) – an example of scrum scaling.

Large-Scale Scrum (LeSS), on the other hand, is a product development framework that extends Scrum with scaling rules and guidelines, without losing the original purposes of Scrum.…”.
Some of the hallmarks of LeSS are:

  • It is the framework that requires organizational de-scaling (simplification), to scale basic Scrum
  • It is the framework that strongly relies on effectiveness of organizational design and system dynamics of multiple organizational layers, departments and spheres of control
  • It is not merely a group of teams doing their own Scrum, while working for different product owners and supporting different products.
    Rather, it is a group of teams (2-8) that works together, synchronously, on the same product and serves the same product owner.

-Read more…

 


More Selected Periodicals:
Unspoken Agile Topics

This paper, originally written in February 2013, brings to light some of the least-discussed topics and consequences of “broadband agilization” that currently take place in the industry.
The materials of this paper are subdivided into two general sections:

  • The first section describes certain impacts that Agile has on individuals and their personal career advancements.
  • The second section describes organizational-level Agile impacts that pertain more to client companies that undergo Agile transformation,
    as well as service-providing vendor companies that deliver Agile-transforming expertise to their respective clients.

-Read more…

Be an Educated Consumer

You just bought a house and decided to renovate. You brought in a contractor to estimate the work that you want done. What is your biggest fear? Here are a few possibilities:

  • The work will not be done.
  • The work will not be done on time (winter is coming and you need wall insulation before it gets cold).
  • The work will be done on time but it will cost you much more than you can afford and more than this job really costs.
  • The contractor is charging you more than he should; he is taking advantage of your ignorance.
  • The quality of the work will be poor but, unfortunately, you will not know this until all of it is finished and you have to move in (after you pay in full).

-Read more…

Fresh Collection of Ad-hoc Agile References:

I continuously collect articles and publications that come from everywhere: colleagues, coaches and trainers, clients, occasional encounters.
I keep a comprehensive list of resources here, categorized by themes.
Some of my most recent samples from the collection are below:



From www.ScrumAlliance.org

Connect with a Certified Coach for Online Coaching!
(re-published from Scrum Alliance newsletter)