In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In part 2 we looked at the roles and how they have adapted, or not, over the years. It is now time to have a look at the key activities and ceremonies.
There are three – five key activities or ceremonies in Scrum (depending on how you take content on the sites), but more often then not it is represented as only three: Sprint Planning Meeting, Daily Scrum Meetings and the Sprint Review Meeting. The additional two sometimes considered separate are the Sprint Retrospective and the Sprint itself.
Sprint Planning Meeting
The original June 2003 site did not have a reference to Sprint Planning.
In the 2007 pdf we have the Sprint Planning Meeting defined as:
Takes 8 hrs. First four are spent with the PO presenting the highest priority product backlog to the team. Allows questions, etc. Then team selects as much Product Backlog as it believes that it can turn into a completed increment. 2nd four hours the team plan out the sprint, creates design.
In both March 2007 and March 2009 the Sprint Planning Meeting definition was:
The Scrum begins when enough of the Product Backlog is defined and prioritized to launch the first thirty-day sprint. A Sprint Planning Meeting is used to develop a detailed plan for the iteration. It begins with the Product Owner reviewing the vision, the roadmap, the release plan, and the Product Backlog with the Scrum team. The team reviews the estimates for features on the Product Backlog and confirms that they are as accurate as possible. The team decides how much work it can successfully take into the sprint based on team size, available hours, and level of team productivity. It is important that the team “pull” items from the top of the Product Backlog that they can commit to deliver in a thirty-day sprint. Pull systems have been shown to deliver significant productivity gains in lean product development.
When the Scrum team has selected and committed to deliver a set of top priority features from the Product Backlog, the Scrum Master leads the team in a planning session to break down Product Backlogs features into sprint tasks. These are the specific development activities required to implement a feature and form the Sprint Backlog. This phase of the Sprint Planning Meeting is time-boxed to a maximum of four hours.
Within scrum.org the definition is now:
The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is created by the collaborative work of the entire Scrum Team.
The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.
The Sprint Planning Meeting consists of two parts, each one being a time-box of one half of the Sprint Planning Meeting duration. The two parts of the Sprint Planning Meeting answer the following questions, respectively:
- What will be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
<< Some depth is then made on these two bullet points where the “Sprint Goal” term is introduced for the first time >>
The ScrumAlliance definition of the moment is again sparse with:
Sprint planning: the team meets with the product owner to choose a set of work to deliver during a sprint.
Sprint Planning Meeting results and opinion
- Planning didn’t matter back in the turn of the millennium!
- Thank goodness we don’t have 8 hr planning meetings anymore. Well, we probably still do but most of it is hidden these days. Lets say your Sprints are fortnightly. Each fortnight you are still likely to spend two hours of planning and backlog management. Then we spend a little time pulling in the right amount of work and talking about it. Hmm I could maybe stretch that out to three hours a fortnight.
- Design; well I haven’t seen that done intensively in a meeting for quite a while. Normally that is done real time as the story is picked up by a developer. It isn’t really a meeting, not in the Feature Driven Design sense of doing some real design work collaboratively. Maybe this is more of a hangover from trying to culturally shift people’s thinking away from massive design efforts and giving them an olive branch to hold onto.
- There is absolutely no detail regarding “how-to’s”. Nothing on how to estimate and nothing on how to get a feature backlog in the first place. The term “velocity” isn’t used to indicate the amount of “pull” of work into the iteration, but it is hinted at. This is somewhat understandable given that all the data captures were taken from overviews but even then scrounging around to find the detail is piecemeal.
- Still hate the usage of “Features” and “Tasks” without any reference *anywhere* to user stories or even potentially epics.
- There is no indication about what is a good size for these tasks or how to break work down.
- Nothing mentioned about ensuring that work is not allocated to the team within this meeting.
Daily Scrum Meeting
The original June 2003 site has the Sprint Planning Meeting as:
A short daily meeting where the team shares status.
-
During the sprint, the team conducts daily scrum meetings.
-
The meetings are held in the same place at the same time every work day.
-
The meetings don’t last for more than 30 minutes.
-
A scrum master is appointed.
-
The scrum master is responsible for asking every team member the following three questions:
-
What have you done since the last scrum meeting?
-
What has impeded your work?
-
What do you plan on doing between now and the next scrum meeting?
-
-
Conversation is restricted to the team members answering the above questions.
-
Meetings can be established for immediately after the scrum meeting based on answers to the above questions.
-
The scrum master is responsible for making decisions immediately, if required to remove impediments to progress.
-
The scrum master is responsible for noting impediments that must be resolved external to the meeting and causing them to be removed.
In the 2007 pdf we have the Daily Scrum Meeting defined as:
Every day the team gets together for a fifteen minute meeting called a Daily Scrum. At the Daily Scrum, each Team member answers three questions: What have you done on this project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Daily Scrum meeting? And, what impediments are in the way of you meeting your commitments toward this Sprint and this project? The purpose of the meeting is to synchronize the work of all team members daily and to schedule any meetings that the Team needs to forward its progress. The team members are inspecting each others work in light of the team’s commitments, and making adaptations to optimize their chance of meeting those commitments.
In both March 2007 and March 2009 the Daily Scrum Meeting definition was:
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.
The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, each Development Team member explains:
- What has been accomplished since the last meeting?
- What will be done before the next meeting?
- What obstacles are in the way?
The Development Team uses the Daily Scrum to assess progress toward the Sprint Goal and to assess how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. The Development Team often meets immediately after the Daily Scrum to re-plan the rest of the Sprint’s work. Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum. The Daily Scrum is not a status meeting, and is for the people transforming the Product Backlog items into an Increment.
Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve the Development Team’s level of project knowledge. This is a key inspect and adapt meeting.
The ScrumAlliance definition of the moment is still sparse with:
Daily scrum: the team meets each day to share struggles and progress.
Daily Scrum Meeting results and opinion
- I want to call out the usage of the word ‘Daily’ here. A Scrum Meeting doesn’t have to be daily. I have seen many highly functional teams performing fine with two or three scrum meetings a week. Do I generally recommend daily? Yes. But it depends on the size of the team and the amount of interaction that is actually needed. Some teams are naturally good at communicating all of the time. Sometimes (especially for non software development teams) the landscape doesn’t change so quickly that a daily discussion is required.
- XP called then stand-ups as did Ritz hotels (doing them back in 1998). But it does seem that Scrum was the first to record the format and espouse it’s value. The term ‘scrum’ here frustrates me. It is a cutesy name that has been applied to something that commercially is more viable if you just call it a ‘stand-up’. The ‘stand-up’ name itself infers the quick nature of the meeting. By standing up members are encouraged to keep the meeting brief and to the point. The visual cue of boredom via fidgeting is heightened. The blue sky term ‘huddle’ equally frustrates me.
- Maybe initial scrum meetings weren’t held standing up – after all 30 minutes is very long! These days I am happy if they go for 10 minutes and I start to fret when they hit 15 minutes. A 15 minute stand-up is a clear indication to me that a team that might not being doing the activity daily needs to do it more frequently.
- Scrum Meetings are hard to get right. It takes a delicate balance of control and autonomy to grow the team’s capability in self sustaining these meetings. Discussions can hint at emergent conflict or team dysfunctions. There is more to running these sessions then just the brief list of objectives hinted above (and more value then hinted above as well). I recently did a decision tree for Scrum Masters when running the Scrum Meeting to help guide them of the sorts of questions and thoughts that they should be considering at the start of the Scrum Meeting, whilst each individual is talking and at the end. It ended up being a three page tree with over 25 nodes. That in itself surprised me. I would love to see more useful guidelines to Scrum Masters about how to facilitate effective Scrum Meetings.
- I am frustrated by usage of language like the “Scrum Master is responsible for asking every team member…” This is a team meeting not a Scrum Master meeting and it sets an incorrect presumption that discourages an environment of autonomy that the Scrum Master is trying to establish. Each individual in the team is responsible for answering the three questions, the Scrum Master is accountable to ensure that they follow through on that responsibility.
- I mentioned in the roles post that I differentiate between the core team and the extended team. It is the core team that is required to provide answers to the three questions. The extended team is invited to attend and may speak but they should not take over the show. I believe it is unfair that extended team members by the above definition are unable to even ask questions. Would you really stop the person who is potentially paying for your product development from asking a question regarding the scope boundary of a particular story?
- There is no mention of a wall (physical or virtual) which is a missing key element of this ceremony overview. It is a smell when team’s talk about the work but never refer to it by touching their cards. Touching their cards ensures that everyone clearly knows which story they are talking about and can more effectively contextualize the conversation. Likewise I would always recommend that mid iteration the team additional walks the wall – talking through every card that is not done to ensure that the sprint goals are re-ignited in their minds. This is a key technique that the overviews are missing.
Sprint Review Meeting
In the 2007 pdf we have the Sprint Review Meeting defined as:
At the end of the Sprint, a Sprint Review meeting is held. This is a four-hour timeboxed meeting where the Team presents what was developed during the Sprint to the Product Owner and any other stakeholders that wish to attend. This is an informal meeting, with the presentation of the functionality intended to foster collaboration about what to do next based on what the Team just completed. The Product Owner and stake holder inspect the Team’s work in light of project goals, and make adaptations to optimize their chance of reaching those goals.
In both March 2007 and March 2009 the Sprint Review Meeting definition was:
At the end of a sprint, a Sprint Review Meeting is held. This meeting is time-boxed to a maximum of four hours. The first half of the meeting is set aside to demonstrate to the Product Owner the potentially shippable code that has been developed during the sprint. The Product Owner leads this part of the meeting and invites all interested stakeholders to attend. The state of the business, the market, and the technology are reviewed. The Product Owner determines which items on the Product Backlog have been completed in the Sprint, and discusses with the Scrum team and stakeholders how best to reprioritize the Product Backlog for the next sprint. The goal for the next sprint is defined.
After the Scrum Review Meeting, the process begins again. Iterations proceed until enough features have been done to complete or release a product.
Within scrum.org the definition is now:
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
This is a four-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints. For example, two week Sprints have two-hour Sprint Reviews.
The Sprint Review includes the following elements:
- The Product Owner identifies what has been “Done” and what has not been “Done”;
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
The ScrumAlliance definition of the moment is sparse with:
Sprint reviews: the team demonstrates to the product owner what it has completed during the sprint.
Sprint Review Meeting results and opinion
- Not much has really changed for the Sprint Review Meeting over time and it probably didn’t need to that much. Personally I prefer having the backlog always prioritised correctly at all times and so a portion of this description is less applicable. That said some people would argue that the intent is the re-prioritise the work that didn’t get done. For me this is a smell and the overview of the process really shouldn’t be handling this exception. The goal is to deliver all of the stories. It should be a realistic goal and in that respect there should not be the need to re-prioritise the work that did not get completed.
- Who is doing what is also less black and white then what is defined above. Why can’t the Product Owner demonstrate what is done? Why can’t the Product Owner and Scrum Master contribute to what went well?
Sprint Retrospective
In the 2007 pdf we have the Sprint Retrospective defined as:
After the Sprint Review and prior to the next Sprint Planning meeting, the ScrumMaster holds a Sprint Retrospective meeting with the Team. At this three hour, timeboxed meeting the ScrumMaster encourages the team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint.
In both March 2007 and March 2009 the Sprint Retrospective definition was:
The second half of the Sprint Review Meeting is a retrospective for the Scrum team that is led by the ScrumMaster. The team assesses the way they worked together in the sprint and identifies positive ways of working together that can be encouraged as future practice. The team also identifies the things that could work better and develops strategies for improvement.
Within scrum.org the definition is now:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. This is a three-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.
The purpose of the Sprint Retrospective is to:
Inspect how the last Sprint went with regards to people, relationships, process, and tools;
Identify and order the major items that went well and potential improvements; and,
Create a plan for implementing improvements to the way the Scrum Team does its work.
The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
The ScrumAlliance’s definition:
Sprint retrospectives: the team looks for ways to improve the product and the process.
Sprint Retrospective results and opinion
- Early versions of Scrum don’t have Retrospectives as a key ceremony as it was taken from Norm Kerth’s Project Retrospectives and Alistair Cockburn’s Reflective Workshops. By the time it was incorporated into Scrum it was a norm for all of the other Agile frameworks.
- Popular believe now is that Scrum is all about “inspect and adapt”. Most people immediately think that this pertains to the stories that are delivered but the reality is it is both the work that is being delivered and how it is being delivered.
- Often the Sprint Review and Retrospective are lumped together and commonly this is why Scrum has kept to the “three ceremony” belief. But the reality is the purpose of the meeting is different from the review and it should be considered a separate ceremony.
- Common failure modes in Retrospectives include a lack of follow up on the retrospective actions or too many actions chosen for resolution. The lack of details about how to conduct this activity would not mitigate these common failure modes. Personally I either make the actions (limited to no more than five) new stories or ensure that at the beginning of the next retrospective they have been completed.
- Nothing about true root cause analysis is described. This would be another failure mode – fixing the wrong problem.
- When the team is familiar with the format of the retrospective I would rotate the facilitation role to further encourage autonomy. It doesn’t always have to be the Scrum Master that facilitates this session.
- If the Retrospective Quadrant technique is used there are very common quadrant patterns based upon the life of the project. Early in the project there is a lot of points around ‘puzzles’ and ‘what is not working/what to do differently’. As the project progresses the numbers shift from the right side to the left. A lack of a shift or a resurgence of puzzles is commonly indicative of a team dysfunction. Often I see a lack of clarity around roles and responsibilities in the ‘puzzles’ area. If a new team member is added it tends to come back again as the team goes through the forming, norming, storming and performing behaviours.
The Sprint itself
In June 2003 a Sprint was defined as:
A short burst of work lasting approximately 30 days during which an executable and other deliverables are built by an engineering team, as indicated by the assigned backlog.
- A sprint lasts no more than 30 days.
- A sprint is undertaken by a cross functional team consisting of no more than 9 members.
- Every sprint has a specific goal.
- An executable demonstrating the goal will be completed by the team during the sprint.
- The sprint team has final say in estimating and determining what they can accomplish during the sprint.
- Once the sprint is underway, new backlog cannot be added to the sprint except that, if the scrum master determines that a new backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint’s executable, and can be completed within the sprint’s time frame, the backlog item can be added. Examples are building a demonstration of the executable for a specific purpose, such as a trade show or prospect.
- If external forces determine that the sprint is working on the wrong thing, a sprint can be halted and restarted with new backlog and purpose.
In the 2007 pdf there was no separate section defining a Sprint other than it being one month.
In September 2010 the Sprint definition was:
The heart of Scrum is a Sprint, which is an iteration of one month or less that is of consistent length throughout a development effort. All Sprints use the same Scrum framework, and all Sprints deliver an increment of the final product that is potentially releasable. One Sprint starts immediately after the other.
Within scrum.org the definition is now:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During the Sprint:
- No changes are made that would affect the Sprint Goal;
- Development Team composition remains constant;
- Quality goals do not decrease; and,
- Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.
Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. Sprints also limit risk to one calendar month of cost.
Cancelling a Sprint
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.
When a Sprint is cancelled, any completed and “Done” Product Backlog Items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning Meeting to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.
The ScrumAlliance has no separate definition for the Sprint.
Sprint results and opinion
- I’ve talked about the 30 days before so I won’t go there again.
- I don’t think enough people understand that the Sprint itself is a sacred timebox. Change is not meant to be put inside of the Sprint with the exception of potentially cancelling a Sprint. This is a weakness and a strength at the same time for Scrum. A strength because it forces the Product Owner to control themselves, a weakness because for some areas of software development waiting a Sprint to change is commercially too long. In these instances most Scrum Masters would then recommend a shorter Sprint length, but in some respect it is not addressing the root cause of the problem – it is providing a framework to somewhat mitigate it.
- It is unrealistic to assume that development team composition will remain constant. In this day and age of rapid change the framework needs to handle and be able to solve this problem. Onboarding will happen. We all know it probably shouldn’t but this is a commercial reality.
- I’m not sure about the wording on the scope being clarified bit. Yes a story is a promise for a conversation and in part of this conversation the scope will have clarification, but what if the developer realises that the story is now four times bigger then expected – the whole goal of the Sprint is in potential jeopardy. Scope should be known enough when the Sprint Planning has concluded so that the team will be able to deliver to it’s Sprint goals. Any changes to scope subsequent to this should be minor. Remember – the Sprint is a sacred timebox away from dramatic change.
- I really dislike the terms ‘scrum’ and ‘sprint’. They were hard terms to sell to management in the mid-early 2000s, they are even harder terms to sell outside of software development where as a framework it is still really useful. Call them “iterations” everyone else does. No-one literally group hugs to form a ‘scrum’ (despite there being evidence to prove that this will result in more effective outcomes). Terminology complaints have been going for a long time now and still there is no change. A number of organisations have to call their implementations something else to get around these non commercially acceptable terms.
- I really dislike the term ‘ceremony’. It is a meeting or even better a repeatable process activity. This is another example of a term being used to make Scrum sound ‘cute’ when really it needs to take itself more seriously.
Agile Forest 
If you don’t like Ceremony, you can always call it a “Ritual” if you so desire. Many scrummers do.
Ultimately whether you call it a Ceremony, Ritual, or anything else, it is a Ceremony/Ritual.
When Japanese workers sing the company song and stretch before their shift is it a Ceremony or a Ritual?
What about the brushing of the teeth?
Ultimately the scrum cancellation thing is something that rarely happens in practice (eg reigning in the PO) even though it should — thus you can see a sprint is a mini waterfall which I cover in detail on my blog.
If one were to take traditional software dev, turn things into 2 week waterfalls, and give cutesy new names/roles to everyone with new ceremonies and rituals, to mask said fact, then one would have Scrum distilled into it’s constituent components.
Jordan
cer·e·mo·ny [ser-uh-moh-nee] Show IPA
noun, plural -nies.
1.
the formal activities conducted on some solemn or important public or state occasion: the coronation ceremony.
2.
a formal religious or sacred observance; a solemn rite: a marriage ceremony.
3.
formal observances or gestures collectively; ceremonial observances: The breathless messenger had no time for ceremony.
4.
any formal act or observance, especially a meaningless one: His low bow was mere ceremony.
5.
a gesture or act of politeness or civility: the ceremony of a handshake.
It isn’t a ceremony… and this only further promotes agilists as cultists.
An event that is repeated on a regular and defined basis is called an activity. But if we call it an activity then that precludes putting these activities together we will get…. a process. And now we have the manifesto problem.
I never said it wasn’t a cult. I think #4 is quite apropros — does the entire team REALLY need to be part of the product demo? I don’t think so, but it’s part of the “ceremony”.
Also I had suggested Ritual
1rit·u·al adj \ˈri-chə-wəl, -chəl; ˈrich-wəl\
Definition of RITUAL
1
: of or relating to rites or a ritual : ceremonial
2
: according to religious law
3
: done in accordance with social custom or normal protocol
If the daily scrum isn’t a ritual/ceremony, I don’t know what would qualify then.
Jordan
Well maybe by your definition it is meaningless, but others might not consider it so. ;P
And by the ritual’s definition it isn’t that either due to it not being ceremonial, not religious and not done in accordance with social protocol. Maybe if it was just protocol that would fit.
Regardless it is a meeting with a standard agenda. As I said before a repeated event is an activity inside of a process. Most just don’t want to call it that because of the negative connotation these days to the word “process”.
Oh, the agile crowd gets upset at anything and everything.
You’re right, people are fed up with the word process though, and I think all these new processes du jour are a leading reason for that.
I think people will start to visibly shake whenever someone says “we want to introduce a new process” because they know that after the fad sheen wears off it’s just Dilbert 3.5.7.
One of the worst things about “process” is that people who tend to worry about “process” — don’t actually build any product. People who build product build product and don’t worry about “process” too much.
People who are selling process make it seem important, but really, process is like what kind of dry markers you use. It’s a tool, but it doesn’t build product. Why it’s become such a huge industry and fad now escapes me.
People who are trailblazers and innovators don’t really ask or care too much what other people are doing, what process, what color dry markers. They know what they want to do and do it.
People who are followers and are unsure of what to do are the ones who worry about trappings like that.
Jordan