The true value of coaching, however, is to build the capability of the existing team. Rather than making choices for the team, the coach provides guidance about the choices available, perhaps making recommendations, and encouraging them to consider the options and choose their actions. The coach teaches the team about techniques or tools that increase their available choices. The coach offers observations about the team’s activities, and helps the team make it’s own observations and reflect on them. The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis.
There’s no need to re-describe Scrum. If you’re on a journey to discover Scrum, I welcome you. I advise you to learn more than Scrum and discover agile & lean.
After attending a few presentations and after reading the small book “Scrum, a pocket guide”, I pleasantly appreciate Gunter’s writing on the topics of Agility and Scrum. I encourage you to read these articles and recommend that little book. It’s written honestly and offers transparent descriptions.
With this are a bunch of excerpts and links (all text is copy-paste of blogs):
Agility is a state, a way of being; of people and of organizations. It is not a process, it is not a method. It is a state from which emerges flexibility, openness for change and fast responses to market changes. Scrum has become the most important Agile framework, allowing people and organizations to achieve this state of Agility. Scrum brings the rules and principles to organizations and their people to grow into this state of flexibility.
The software industry has for a long time been dominated by industrial views and beliefs. The universally accepted paradigm was in fact a copy-paste of old industrial routines and theories.
Although it was not widely and consciously admitted, but this did put the software industry in a serious crisis.
The House of Scrum
The house of Scrum offers an open view on the world, while protecting from rigid behavior. Its inhabitants remain flexible at all levels to better deal with uncertainty, and shape -not predict- the future. They sense, probe and adapt at all levels. Scrum drives building better software products, and faster. In 30 days, or less. But, most of all, it restores energy and work pleasure for all involved.
Less known and probably under-highlighted, but therefore not less important, are the core Scrum Values upon which the framework is based.
Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior and our actions. In a Scrum context the decisions we take, the steps we take, the way we play Scrum, the practices we add to Scrum, the activities we surround Scrum with should re-enforce these values, not diminish or undermine them.
In a context of Scrum the described inverted form of accountability leads to exactly the opposite of the Scrum tenets; cross-functional collaboration, utilizing collective intelligence, bottom-up knowledge creation, shared goals. Yet, accountability is essential. The false application of it doesn’t reduce its importance. Removing and avoiding accountability has disastrous effects as well; no vision, no focus, no direction, no choices, endless discussions and meetings, indecisiveness; a Gordian knot.
Scrum foresees a clear accountability for each Scrum role:
The Development Team is accountable for creating releasable Increments.
The Product Owner is accountable for maximizing the value of the work.
The Scrum Master is accountable for the understanding and application of Scrum.
These accountabilities are separated, yet all are needed. It is why these roles need to collaborate as a Scrum Team with a shared responsibility toward the organization, its customers and the wider ecosystem.
Done Increments are THE way to achieve agility through the empiricism of Scrum.
The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.
The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.
Scrum, actually, in itself is not the purpose. Scrum is a tool. Scrum enables people to live the art of the possible, to make the most out of every single day constrained by their means, to maximize the value of their work in the face of uncertainty.
Scrum, actually… is a means to an end, a tool designed for a purpose: people, agility, value.
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. (…) This Increment is useable, so a Product Owner may choose to immediately release it. (Source: The Scrum Guide)
In Scrum, actually… releasable means all work done to release to the market. Instantly.
As with Agile, the Scrum Values and Scrum’s fundamental roles and rules as described in the Scrum Guide don’t change with scale. But scaled implementations of Scrum require different tactics in implementing the rules.
In Scrum, actually… Agile is the DNA driving the behavior throughout the software development ecosystem.
Agile and Scrum, actually, are two inseparable ingredients in a software development ecosystem.
Scrum’s events serve the empiricism that Scrum brings to software development. Empiricism thrives on inspection & adaptation. Inspection & adaptation happens at a frequency, in regular intervals. Adaptation only makes sense when inspection is done against reality, when the actual situation is made transparent.
In Scrum, actually… meetings are opportunities where people meet to change their mind.
Try something you believe might work for you. Inspect it, adapt to your findings. Repeat. When heavily constrained in doing this, sticking to the guidance of having 3-9 people in a Development Team is a good idea.
Velocity in Scrum actually is an indicator of productivity, an indicator of how much software, preferably releasable software, a team has produced in a Sprint. That in turn is not a promise, nor a contract for the future. Predictions are fragile. Empirical process control has the potential of antifragility. We embrace complexity.
In Scrum, actually… velocity makes most sense if a measure of a team’s capability to create releasable software.
Once upon a time, there was a marketing person with great ideas for a new software application.
He hired a business analyst, who described all those ideas in formal specifications fully documented business requirements (including use-cases, business rules, exceptions …). This deliverable was handed over to a User Interface / User Experience expert who created a detailed User Interface (including wireframes, site maps, screen flows, mock-ups,…) and described all the user interactions. Next, a functional analyst translated those requirements to an available specification and tried to figure out how to connect them to existing infrastructure and systems.
Given the functional specification, a technical analyst created a technical specification and application design to capture all the given information in a deliverable that would make sense as input for development. Meanwhile, based on that User interface specification, a visual designer, individually, made stunning pixel-perfect graphic designs for every screen of the application. A copywriter was sometimes assigned to write on-screen text labels and copy based on the wireframes. And even sometime later, a tester was given the assignment to understand the requirements and write test scenarios.
Development was about to get started!
Sometime later, during development, some concerns arose about the application’s User Interface, and a usability engineer reviewed the User Interface specification to give some advice and remarks.
So, what do we observe?
The work goes sequential
Individuals doing their own thing, producing output: deliverables, documents!
Time passes by
Handoffs, with potential gaps for misunderstandings, misalignments, information lost in translation
Let’s retrospect.
Silo teams
The goal was to create a new software application – with probably a fantastic idea in my mind and initiated by a great business case. Where is our software?
Focus on outputs, not outcomes. People are appreciated for their output: mainly documents and the quality of those documents.
Those documents are written by an individual or a group of individuals of the same expertise – documents are passed on (with or without explanation). The output of one phase is the input of the next phase. Lack of common understanding (not by the fault of the individuals), each needs to re-interpret the previous work—no real sense of ownership.
It’s a very time-consuming process. From inception to the actual start of development, it can take months – depending upon the size of the project.
Assumptions, lots of assumptions! Hypotheses based on those assumptions. As great as it might be, a requirement spoken by the guy from marketing remains an assumption until proven by the market: feedback from actual end-users: the customer.
There is little to no opportunity to react and correct the design of the new software application when new insights or market conditions come up meanwhile developing.
Probably the whole process is overseen and controlled by a commanding officer.
Where’s our marketing person? Out of sight
A chain is only as strong as its weakest link.
Teams used to a sequential process have become accustomed to handoffs between specialists. Each group passes off their work to the next group. These handoffs include overhead in meetings, documents to review and approve, waiting time, etc. Anything that does not directly contribute to the project’s goal: creating software is waste.
Let’s reconsider.
Once upon a time, a marketing person had a great idea for a new software application.
The sponsor gathered a team with expertise in IA/UI/UX, usability, customer engagement, front-end/back-end development and testing. The team formulated the new application’s business goal and desired business outcome with the marketing guy. Together, the team made this set of skills, not an individual, for each required expertise.
The team focused on the outcomes that would address the primary customer need of our application. The idea was conceptualised lightweight: the team formulated some hypotheses: valuable features that they considered a good collection for a ‘minimum viable product’ and a set of metrics to verify those hypotheses. Next, the team draw some UI sketches on paper. The team set out a test by linking the UI sketches to an “interactive” prototype for internal validation. Considering the received feedback, the team refined that small set of features to a user story level with the main acceptance criteria.
The team decided to prototype directly in HTML/CSS as this was the preference of the web developers. The team organised a user test with key customers and external (non-customer) people. These tests and the earlier defined metrics concluded and prioritised several improvements. Collectively, the team came up with the adaptations. With minimum documentation effort (again: main wireframes and a list of agreed-upon decisions), They improved the prototype and discussed a subsequent set of functionality.
Meanwhile, the needed services were encoded and deployed to connect the front-end with the back-end system. The next test showed the application with actual back-end data.
Over time, the team improved the product with customer feedback. They included new insights, dropped a few – previously considered “must-have” – features, and integrated a new online service that appeared to be an excellent fit for the solution.
So, what do we observe?
The focus is on creating working software; that’s what we care for!
Documents do no solve user’s problems, working software does.
The focus is the outcomes; the focus is the vision. The team liberates itself of endless discussion regarding functional features. The attention is directed on user needs, and in that problem space, possible solutions (hypothesises) to address those user needs are presented and challenged.
Feature development is prioritised. There’s no all-inclusive upfront analysis, and there’s no big design application design up-front. There’s no detailed product functionality roadmap. The design emerges, or instead, there’s a good design upfront.
We eat the elephant in small chunks, but we prioritize the chunks.
The team organises itself to collaborate. Insights, proposals, experiences, expertise are collected, and in a healthy synergy, the team shares and co-creation happens – with the customer. The customer is central.
Instead of an open-loop system, the project is organised as a closed-loop system: actual feedback of end-users is incorporated iteration-by-iteration to evolve the application and its features. The “apply-inspect-adapt” cycle is a “probe-sense-adapt” approach. The team plans for experimentation, the team is ready to react when new insights arrive. There’s no anxiety about changes.
Lean UX cycle
What about documentation? When required, additional application designs or an overview of architectural components is delivered. Besides that, the product (software) itself is the documentation. Visual elements are documented in the application itself. The developed front-end is the library of reusable components. The web services themselves are established and are self-explanatory in terms of logic.
Modern software development environments and software craftsmanship practices allow this kind of rapid application design, construction, testing and delivery iteratively and incrementally.
Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we
Mensen en hun onderlinge interactie boven processen en hulpmiddelen Werkende software boven allesomvattende documentatie Samenwerking met de klant boven contractonderhandelingen Inspelen op verandering boven het volgen van een plan
Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.
Disclaimer: this article expresses my personal opinion and is based upon personal experiences. You can consider this a rant, but I am open to any constructive criticism. Yes, the article shows a single view on the state of affairs and everything depends upon the context and the situation. The only thing we can do is to learn from experiences and work together to build great software products and improve the world we live in.
Traditional development is like being the passenger on a bus tearing down a serpentine mount road while being driven by a drunk
The fallacy of the perfect requirements
Let’s define all requirements up-front. Let’s create all design up front. Let’s freeze those requirements and let’s develop based upon that set of requirements.
Great!
So, what’s wrong?
Requirements do change
External and internal factors cause change. The world around us changes. Technology advances at a fast pace. Competitors arrive with new ideas. Legal requirements are imposed. We get feedback from the market: users, customers, competitors. We learn as we do.
The decay of requirements during the project life-cycle. Even in the best case, requirements will change inevitably. In the worst case, only the half of your requirements will be valid. In case the planned delivery date is not met, the situation gets worse: it becomes more difficult to ever meet the actual business needs. Requirements further decay.
The assumption that you can design and define all requirements up front, it’s simply false.
Complex product and software creation is a wicked undertaking. Software is intangible. Knowledge is in people’s heads. Delivering an all-inclusive requirements specification document and aiming at a 100% satisfying developed software application will simply not happen in reality. It’s a self-fulfilling prophesy.
As soon as the actual end-users (customers) consume the product or software, opinions are formed and feedback is given. By using the software product, we learn about its use and instantly potential improvements emerge. The act of delivering the software causes the requirements to change. The longer it takes to get feedback about the software product, the longer it will take to converge to a solution that satisfies the user needs. In fact, requirements change while the software is being developed.
So what happens in traditional sequentially phased product development?
Lots of change requests.
Lots of defects; a large part of those defects are actually improvements based upon (testing) feedback (so, change requests).
Discontented business stakeholders; impatient end-users
Feeling of lost opportunities
Delay in delivery
Delivery of value at the very end
In a sequential phases project, the value is only delivered at the end. The risk is only decreasing at the end.
The longer the duration of the sequential phases, the larger the devastating effect will be. The longer it takes to define the requirements and to deliver the software, the more substantial the change will be. The later in the software development life-cycle the change is requested, the more costly it will be.
Figure 1: The cost of change in the lifetime of a project. Red line: in a traditional sequential project, the cost of change becomes increases dramatically as the project progresses. Grey dotted line: the cost of fixing defects is similar. Blue line: the ability to respond to changes goes linear down as the project progresses. Figure 2: Red line: The cost of change in a traditional sequential project. Blue line: the cost of change in a realistic agile project approach. Grey line: the cost of change ideally in an agile project approach.
The fallacy of end-game testing
Let’s fully develop the software product, and next let’s test everything at the end.
Great!
So, what’s wrong?
Bugs, defects are discovered late in the development process. The cause of the defect can be anything: bad design, mistake in coding, integration issue or simply a misunderstanding or misinterpretation in requirements.
So what happens in traditional sequentially phased product development?
Defects are reported late. There’s little to no time left to fix all defects. Only the functionally blocking defects are solved to get the application into an acceptable state. Any defects that “scratch the surface” or points for improvement are postponed to a “phase II” or “aftercare release”; which hardly happens, or which does not address all issues. And most importantly: this will happen way too late. In production, we call these “production incidents”.
People are pushed to work overtime and to do weekend work. Bugs must be fixed. Retesting must be done. Remember, we are in the project phase near the end (development has been done) and business stakeholders are impatient to release.
…with the software in production, fixing bugs is akin to repairing a car while it is driving down the road, long after it has left the drawing board, the assembly line, and the dealer lot. It’s as expensive to do as it can possibly be.
In sequential development learning happens late. Changing or removing requirements causes rework at a high cost and may break other functionality. Fixing defects is costly.
Let’s define and develop all components or software layers separately. Next let’s have one phase at the end to integrate it all.
Great!
So, what’s wrong?
Big-bang system integration will not work as planned. An upfront system analysis or design will not be able to envision or control the full process of system integration. In real life complex software development, something always will pop-up or go wrong. The assumptions regarding the integration will not withhold, due to changes, constraints or simply unknown unknowns that are about to happen along the way. Real knowledge on how to integrate the system is acquired as you’re integrating: too late.
So what happens in traditional sequentially phased product development?
Integration problems at the end of the project: these demand ad-hoc and root-cause analysis but without the ability to systematically fix the underlying issue.
Delay in delivery and incomplete system integration means the risks are still high: not all potential issues have been discovered.
The fallacy of a fully planned-ahead schedule
Let’s create an end-to-end project plan, schedule all activities, plan and assign all resources, map all dependencies. Oh and additionally, we will add some buffer, as compensation if something unexpectedly happens – you never know. We also define the critical path and monitor it as a maniac.
Great!
So, what’s wrong?
We are assuming we have planned all the knowns, we have added some buffer for the known unknowns. But you cannot schedule for the unknown unknowns. We are assuming that we are good at estimating effort of all activities of the different project phases. Moreover, we estimate and schedule all activities upfront at the beginning.
Software creation is an inherently complex process. Given the multiple sources of potential changes and discovery of the unknown unknowns along the way, the project will never be executed as on schedule. In the process of creating, designing, developing, testing, new information and knowledge are constantly acquired.
Managers expect they can plan for all the variables in a complex project in advance, but they can’t. Nobody is that smart or has that clear a crystal ball.
The Cone of uncertainty indicates the degree of variability in estimates during the lifetime of the project.
Humans are bad as estimating, even when given historical data. Estimates are considered as the truth, they become a self-fulfilling prophesy. The whole project is built upon those estimates and milestones are defined. Expectations are set and promises given. It becomes a dysfunctional model. The project progresses, but almost no one dares to truly acknowledge those initial estimates may be off. We don’t want to break the expectations. The whole project is built upon initial estimations which are taken as commitments. No empirical process is in place to get in touch with reality and to adapt.
So what happens in traditional sequentially phased product development?
Project managers track and update their schedule, pushing out activities ad hoc to resources. Metrics are used in waterfall because we had no idea what was happening so we try to measure anything.
Friction between project and sponsor
The blame game
The typical “IT projects always have delay” situation
Problems to actual change something about the situation: a lot of investment in infrastructure systems, development has been done. Rework causes changes to stuff already built.
Value is delivered at the very end of the project
The fallacy of gated phases, experts working in silos and hand-overs
Let’s ask the business owner to define the business need and a concept. Let’s ask the business analysts to translate that concept and deliver the business requirements. Let’s ask the visual designers to make stunning design. Let’s ask copywriters to write content and text labels. The functional analysts will create a functional speciation based upon those requirements. Next, a technical analysis will be performed, followed by a technical design. Those specifications will be accomplished with a set of non-functional requirements, and an architectural design. Finally, this will converge to a development specification. Let’s start development! Some period after, the testers start looking into requirements to write test scenarios.
Great!
So, what’s wrong?
It’s not efficient. It’s very time-consuming. Handovers between experts in silos will be a source of misunderstandings, misinterpretations. The business owner of representative will never talk to the developer. Requirements are lost in translation. A change or gap correction in the specification will be costly, often not accepted. No ability to act upon changes, resulting in missed opportunities.
Missed opportunity for a creative product development process: different people working in the different phases of the project carry their own opinion regarding their area of expertise. The concept and the design of the product therefore will be influenced / impacted. Unfortunately the sequential nature of the project does not allow incorporating all that feedback in a meaningful way.
So what happens in traditional sequentially phased product development?
Lots of time (and money) wasted on handovers, alignment between teams
Missed opportunity for a creative product development process
Lack of common understanding
No team alignment
Loss of intrinsic motivation, work satisfaction
To sum-up
A believe that an old industrial paradigm can be applied to software manufacturing. A believe that defining and planning the full project in advance will lead to a successful on-time delivery of the project. After several decades of software development, many new technologies, new practices came to existence, but the traditional manufacturing approach to create software products proves to not be successful.
A business analyst, or more generally, a business consultant, works together with multiple stakeholders to deliver the greatest value and is equally a driving force to enable change in an organization by defining needs and recommending solutions.
As such, business analysis is a much needed practice. Business analysis is an umbrella term: many other specific job titles exist. There even exists a business analysis body of knowledge and a business analysis career path (to take you to a mgmt. level) (a pity my career doesn’t advance that fast…).
In fact, performing business analysis can be a much satisfying job.
Business analysts as a workaround for organizational problems
Unfortunately – based on my experiences, business analysts are often squeezed between business and IT stakeholders. A group of business analysts is put in place to go on with the continuous task of translating needs and requirements, communicating scope changes from business to IT, and communicating constraints and drawbacks vice-versa; and this continues for the full project life-cycle.
In fact, business analysts are needed as a workaround for organizational problems. Organisations who cannot manage to have a direct, constructive and collaborative approach with all stakeholders will need a unit of business analysts to – what’s traditionally called – bridge the gap (note: in some organisations this figural speaking “gap” is the size of the grand canyon). In such a setup, the output of business analysis mostly happens in the format of some deliverables (documents), with a handover to the next stakeholder – this handover is, by definition, a form of waste.
It’s directly related to the organizational structure. Organizations traditionally shaped have separate silos “business”, “IT”, “operations”, with often intermediate organizational units to make all these people work together.
In a setup where people are collaborating directly in the same team, this gap will naturally be smaller or even dissolve. Claiming business and non-business people cannot directly interact and collaborate is a false prejudgement and it’s even plain insulting. I strongly believe it’s in the vast interest of an organization to share experiences, to create an environment that stimulates learning and improvement, and where people are encouraged to engage in practicing secondary skills.
At the team level
It’s clear that on a team level, the agile spirit translates into a cross-functional team. On the one end of the spectrum, there are small companies, start-ups and spin-offs which naturally have a spirit of cross-collaboration, cross-duties and ownership as a whole. On the other end of the spectrum, in large organizations, the challenges are profound. It’s not straightforward to create cross-functional teams and to establish collective ownership.
Different person profiles may exist in a team or by definition are not allowed to exist. A team – as a whole – will need to be able to perform the different tasks necessary to build whatever they are building – if they don’t have the skills or competences available within the team they rely upon an external resource, or more preferred: they acquire that skill or competence by learning.
The product owner is the business representative responsible and accountable for maximizing business value. That person is responsible for maximizing business value. While elaborating business needs, he’ll perform business analysis (in the broad sense of the term).
The team – together with the business representative will put effort to understand the business needs, analyse and refine and to communicate those business needs and requirements – as necessary; in any kind of format as necessary (oral or written).
As business needs tend to change quickly, we prefer to define the requirements fine-grained for the next work items (1 item in a single-piece work flow, or if working iteration-based, for the next iteration). Other items for the future remain coarse-grained defined. As we proceed with the work, the team analysis and refines, together with the product owner – who also constantly re-assesses the priority and value.
Business analysis encompasses many other activities than simply translating business needs. Business analysis is a skill performed as a team, spreading knowledge about what the business wants within the team, and trying to minimize any hand-off. In fact, this description applies to any skill. Earlier, we wrote a post with the question if business analysis still exists in an agile team. Of course it does. But take care: we do not want to establish a business analyst who acts as customer proxy or proxy product owner. Business analysis is performed collaboratively by the product owner and the team.
When you put a group of individuals together, don’t expect them to act as a team “in a magical way” from day 1.
‘We like to bring together people from radically different fields and wait for the friction to produce heat, light and magic. Sometimes it takes a while.’ (author: Brad Veley)
Let’s explore the “dynamics” and emotional intelligence of a team and how a common understanding can help the team to get to a “well performing” state (besides the emotional intelligence, it’s absolutely necessary to have good technical skills and modern day engineering practices, e.g. in the context of product / software development – but that’s not the subject of this article).
It’s known that emotions and behaviours in a group are contagious and can have a dramatic impact on a team. After all, we are humans and not robots are we? You could say, one person is more professional than the other and can put aside any emotions in a professional environment. On the other hand, some degree of emotional binding is necessary to get to an effective team.
What’s important for a team?
We would like our team to be focused, be collaborative and have a sense for common purpose.
A team manifesto is a team-designed agreement for a set of values, behaviors and social norms. It’s a vision for the team built on a common set of principles and values.
An example of the characteristics of a team with high positivity / high productivity (source: team coaching international)
Team high positivity high productivity Source: Team coaching international
In general, a set of positivity strengths and productivity strengths are necessary to come to a well performing team.
A team assessment by doing some team diagnostics can reveal the current state and determine points for improvement.
How do we get going to define a team manifesto?
In case of a new team, you can do a profile card exercise so that people get to know each other.
You can also do a personal agility rating exercise. This is useful for individuals themselves and for a coach as he can use this info to improve on agility on an individual basis in the future.
Next, you let the team define what it means to be a “team”.
The team discusses any other principles and values it considers important.
Next, the team garters all the input on a big flipchart or board and creates a team manifesto.
Create a manifesto Source: http://www.slideshare.net/MelissaKane/create-a-project-manifesto
Please note: when working with multiple teams, the teams could define a manifesto per team – this seems the most natural as teams will be different. You could also define a manifesto on the level of the project / programme, including a vision for the product or service being built.
The House of Scrum
