Everyone loves Agile. You can tell, because everyone is doing Agile.
Or are they?
There’s always been some debate about just what “Agile” is supposed to mean, despite the conciseness and clarity of the four value statements in the Agile Manifesto. But in recent years, the debate has grown heated.The Two Camps of Agile
The Agile community is divided. It bifurcated several years ago. Camp A comprises those who want to sell packaged Agile to Late Majority and Laggard adopters. They’re all about ceremonies, events, artifacts, practices, frameworks, and certifications.
Camp B comprises those who emphasize the core values and principles of agility as expressed in the Manifesto, and as those values and principles have evolved through mindful practice over the years. These are the people you hear saying they want to “take back Agile.” They mean they want to take it back from Camp A.
I find it interesting that all the authors of the Agile Manifesto are in Camp B. I suspect there’s information to be gleaned from that fact.
My son, who is now in the workforce full-time as a software developer, asked me what “agile software development” is supposed to mean, in a nutshell. I said it meant taking a step, assessing the outcome, learning from that outcome, adjusting our practices, and then taking the next step. He thought that made sense.
Another way to say it is that “agility” basically means an organization has fostered a culture of continual improvement. The alternative is an organization in which people simply learn a defined process and follow it by rote, over and over again. It makes no difference if their process has the word “agile” in its name.
People have expressed the same idea using different terms for quite a long time. It’s the same general idea as double-loop organizational learning; as Plan-Do-Study-Act (formerly known as Plan-Do-Check-Act); as Boyd’s Observe, Orient, Decide and Act loop; in a narrower context as the Five Focusing Steps in the Theory of Constraints. The general idea plays a role in many models of human decision-making and organizational improvement.
In a 2014 article entitled “Time To Kill Agile”, “Pragmatic” Dave Thomas writes:
Here is how to do something in an agile fashion:
- Find out where you are
- Take a small step toward your goal
- Adjust your understanding based on what you learned
There’s that loop again, expressed in slightly different terms. Dave also writes:
Let’s abandon the word agile to the people who don’t do things. Instead, let’s use a word that describes what we do. Let’s develop with agility.
Camp A is interested in qualifying for the label, Agile. Camp B is interested in working with agility.
Another Manifesto author, Alistair Cockburn, writes in a 2015 article entitled “Rediscovering the Heart of Agile“:
All through 2014, I found myself saying: “Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the center of agile. […] [I] found that when I was encouraging getting back to the center/heart/spirit of agile, I kept emphasizing these four things…”
The folks at Industrial Logic, who have been involved with Agile since before the the idea was codified in the Manifesto, have another model. It’s based on four key ideas:
- Make People Awesome
- Make Safety a Prerequisite
- Deliver Value Continuously
- Experiment & Learn Rapidly
So, we see a recurring theme in Camp B. It’s one variation or another on the idea of continual improvement based on observing our results, learning from them, adjusting our practices, and moving forward again.
Notice what’s missing: New job titles, new process frameworks, new artifacts, new ceremonies.Can the two Agile camps be reconciled?
This notion of “taking back agile,” of “working with agility” rather than trying to “do Agile”, might lead us to follow a pattern based on the four or five repeated steps in the various models for improvement. To address the needs of large organizations that are only now interested in agility, we have to apply the core values in a practical way.
It can be done.
Plan…Find out where you are…Observe, Orient…Reflect…
This implies you need a way to understand both your present state and your goal state. The notion of direction comes to mind. This reminds me of the LeadingAgile Compass, the basis of our model for helping organizations evolve toward their goal state.
The four quadrants of the Compass describe the way organizations understand the needs of their customers and how they deliver value to those customers. Many people aren’t aware of where their organization currently stands, and some may not have a clear idea of where they want the organization to be. The Compass can be very helpful in this situation.
Do…Take a small step toward your goal…Decide, Act…Collaborate, Deliver…Deliver Value Continuously…
To accomplish this, we need to have a working definition of value. We need to have a stable, predictable method of delivery. We need to have measurements so that we will have a basis for assessing our outcomes and learning from them.
All of that reminds me of the LeadingAgile Roadmap. The idea is that the most effective way to achieve organizational transformation is to begin with delivery and build from there. Based on the triad of structure, governance, and metrics & tools, predictable delivery leads to trust. Trust leads to a loosening of formal controls. Autonomy leads to greater adaptability.
Study, Act…Adjust your understanding based on what you learned…Reflect, Improve…Experiment & Learn Rapidly…Observe, Orient…
For this, we need some sort of quantitative or qualitative measures so that we can compare our original state with our current state and see if we’re headed toward our goal state.
This is baked into the LeadingAgile Roadmap. The triad of structure, governance, and metrics & tools provides a structure within which continuous flow can occur, methods and processes (governance) to achieve delivery, and an objective basis to assess progress.
The whole repeated process of delivering with agility is encapsulated in the LeadingAgile Journey. The model is based on five milestones we call Basecamps.What Are The LeadingAgile Basecamps?
Basecamp 1: Getting Predictable. Focus on teams, backlogs, and working tested software. We’re interested in gaining clarity about the backlog, achieving predictable planning, and quantifying delivery performance. Usually, a key area of focus is breaking organizational dependencies, which tend to be a high cost factor in most organizations.
Basecamp 2: Reducing Batch Size. Focus on release planning, technical practices, and flow-based metrics. Working in large batches is second only to dependencies as a cost factor.
Basecamp 3: Breaking Dependencies. We’ve already addressed organizational dependencies above the team level. Now the organization is positioned to address cross-team dependencies in the IT area. This enables a focus on legacy refactoring, continuous deployment, and DevOps.
Basecamp 4: Increasing Local Autonomy. At this stage, the organization is positioned to enable team-level autonomy without the risk that is incurred when people attempt to introduce autonomy without preparing the organization to support it (a fundamental error in most Camp A solutions). This involves team-based funding, software capitalization, and adaptive governance.
Basecamp 5: Investing to Learn. The organization is now optimized to support continual learning and adaptive creation of emergent solutions. Focus is on outcome-based, innovation-focused design thinking. The end result is an organization in which double-loop learning is the norm.
The approach pragmatically acknowledges the realities of large organizations without compromising the core values of agility. It’s a win-win.
Mutual respect and caring are the cornerstone to the team’s success and it needs to be integral to their culture and beliefs. Not just saying but living the belief there are no heroes or scapegoats. Everyone, including the business, executives, team members and leadership must collaborate and share in celebrating the successes as well as accepting responsibility for setbacks and failures.
Everyone must have the right attitude and commit to not only DOING as needed by attending the ceremonies or following the process and practices but truly wanting to BE part of the solution by willingly changing the way they think, work and collaborate. (Senior Agile Coach Jerry Doucett)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Last week, I argued that the Agile Manifesto defines the Agile mindest. If your attitudes and values are aligned with the Manifesto, then you can claim to have the Agile mindset. This post is the short form: the conclusions without the reasoning, plus the questionnaire. For more explanation on why I chosen these questions, see Five Simple Questions To Determine If You Have the Agile Mindset.
You can download the questionnaire in PDF format.
The Manifesto for Agile doing what we doWe are uncovering better ways of doing what we do, by doing it and helping others to do the same. Through this work, we have come to value:
Individuals and interactions over processes and tools
Customer visible value over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
– The Agile Manifesto, www.agilemanifesto.org, as paraphrased by Peter StevensWhat is the Agile Mindset?Someone who has the Agile mindset is in alignment with the first sentence of the Agile Manifesto: The Agile Mindset is a learning mindset.
Someone with an Agile mindset knows what they do, besides making money! What value do you bring value to those whom you value? Someone with an Agile mindset is uncovering betters ways to do what they do, both by doing it, and by helping others to do the same. This is about advancing the state of your art, having time to improve your skills and technology, and learning and sharing beyond your own four walls.
Someone with an Agile mindset knows what they value. The have reflected on the Values and Principles of the Agile Manifesto and found their own beliefs to be largely in harmony with those expressed in the Manifesto. Values are a guide to decision making, so their decisions will be aligned with the Agile Manifesto as well. Perhaps they have additional values. Perhaps they have reason to disagree with one or more of the values in their context. The less relevant you consider the Agile values, the more you should question yourself on whether you really have the mindset!
Finally someone with an Agile mindset knows why they value what they value. Values are not to be blindly followed. You may value other things beyond the 4 values expressed in the Agile Manifesto.
Peter's 5 Questions
- What do you do for those whom you value? The answer must contain a verb and is not “making money
- Are you uncovering better ways of doing what you do, by doing it?
- Are you uncovering better ways of doing what you do, by helping others to do the same?
- Have you reflected on the values and principles of the Agile Manifesto and what they mean for you?
- Can you concisely explain your values and why you value them?
Downloading and Using the AssessmentYou can download and use Peter's 5 Question Assessment. It is licensed under a Creative Commons Share Alike Attribution 4.0 License.
I guest-starred on the Ruby Rogues podcast in August 2016. We had a wide-ranging talk discussing how Agile has changed over time, evolutionary design, large-scale Agile, and more. It's one of my favorite podcast appearances to date. Well worth the listen.Listen to it here.
I've been doing a lot of work with multi-team development projects recently, and this has resulted in two good talks on large-scale Agile.Scaling Beyond the Enterprise
My first talk was a keynote for Agile India in March 2016. It provides a good overview of the issues that come up, some of the solutions, and discusses my approach is different from existing approaches to scaling.Scaling Beyond the Enterprise
The brilliance of early Agile methods was their non-conformity. They rejected conventional wisdom about how software should be created and substituted a new reality: one where collaboration, adaptation, and continuous improvement were more important than rigid processes and plans. At first, many people rejected these innovations, but Agile stood the test of time. Now it's won the day.
When people talk about scaling Agile, they forget those insurrectionary roots. They focus on what's palatable to the "enterprise:" how to make Agile safe, non-threatening, and acceptable--how to make it more conventional and conformist. In doing so, they risk losing the innovations that make Agile work so well.
What if we stopped worrying about what's safe and acceptable? What if we went back to those innovative roots? What would Agile look like if we scaled beyond the enterprise?
Come find out.Rethinking Scaling
At the I T.A.K.E. conference in Romania, in May 2016, I keynoted on this topic again. This was an audience of developers, so I took a deeper look at the architectural and team structure considerations. There's a bit of overlap, but it goes into more detail with more examples. I'm particularly pleased with how this talk came out: it's covers a very solid list of things to think about as your company grows.Rethinking Scaling
That feeling of a successful startup. A handful of people in a room, getting shi...ny things done. Everybody working together, all cylinders firing. It's intoxicating.
That feeling of a great XP team. A cross-functional team, all in a room, getting shi...pping done. Everybody working together, sharing responsibility, creating great code. It's impossible to forget.
But what do you do when the startup IPOs, and the 12-person company is now a 1000-person behemoth? What do you do when the XP team grows, and you have 100 people working on a product, not ten? How do you keep those great small-team dynamics in a big organization?
When people talk about scaling Agile, they focus on what's palatable to the "enterprise:" how to make Agile safe, non-threatening, and acceptable. But what if we aren't in that kind of company? What if we know what it's like to be great, but we're too big to do it the way we used to?
Let's set aside the brand names, consulting companies, and enterprise certifications. Let's look at the possibilities of large-scale Agile at its best.
The Agile community has been arguing about whether estimates are a good idea or not for a while now. In this talk at Øredev in November 2015, I think I did a pretty good job of threading the needle. I talk about how and when to estimate, and why you might not want to.Estimates or No Estimates?
There's a debate raging in the Agile world: should we estimate, or not? Lost in the noise are more important questions: When should we estimate, and why? When should we not estimate, and why not?
As with so many Agile questions, the answer to "should we estimate?" isn't a clear-cut "yes" or "no." Instead, the answer depends on what your team is capable of, what your organization needs, and how to best balance the two.
We'll take a deep look at how estimates work, why they work, and when and why to discard them. Along the way, we'll encounter surprising insights about the nature of Agile development and the teams that use it.
I keynoted at Agile Australia in June 2015 and InfoQ recorded it. If you know somebody who's doing "Agile in name only," they should watch this video. Here's the blurb: The Reward
For an approach that emphasizes simplicity, success with Agile is surprisingly difficult. Some teams see amazing results. They're able to respond to changing needs, deliver new releases every day, and do so with nearly zero defects. Other teams complain that Agile makes things worse, not better. They get less done and spend more time in pointless meetings.
What is about Agile that creates such different experiences? Let's take a step back and look at what makes Agile work. What's the point of these Sprints, stories, Scrums, and other practices? What leads to success and what leads to struggle? It's time for a frank discussion about what it takes to succeed with Agile.See the presentation and transcript here.
To ensure consistency and a shared understanding, whole teams (including the business, IT, and their leadership of executives and managers) should receive a common skills development and education experience in proper Agile Thinking, the Scrum Framework, aligned practices and mindset training. Coaching should then reinforce this new knowledge and encourage appropriate behaviours to turn these new practices into habits. Indeed, learning should be a continuous cycle and endless journey towards excellence, and Scrum leverages this through frequent retrospection and continuous improvement.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quote: Whole teams should receive common education experience appeared first on Agile Advice.
Curious about unconferences? Perhaps you’re thinking of running one? Or maybe you are invited to an unconference or open space, and the organizer sent you this link to describe how it works? If so you’re in the right place!
This doc is a high-level summary. For more details and facilitation instructions, see the ebook How to run an internal unconference.What is an unconference?
An unconference is basically a conference without predefined topics. There is a high level structure and theme, but actual topics are generated by the participants on the spot, and breakout groups are formed dynamically based on interest and relevance.
If you know what an Open Space is, an unconference is really just an Open Space event with some added structure at the end to make it fit for company-internal events.
This is a pretty awesome format for cases where you want a super-flexible and participant-driven agenda and structure. I’ve been using it for years at Crisp, Spotify, Lego, and other clients, and it tends to spread virally within organizations. I’ve done it mostly with groups of 20-80 people, and people often say things like “all conferences should be like this” or “best conference I’ve ever been to!”
Disclaimer: I didn’t invent the term unconference and I don’t own the definition of it. So this is just my take on it.What are the benefits of this format?
The key benefits of this decentralized setup is:
- Higher energy level. People focus on issues that matter to them.
- Less up-front planning. No need for someone to set up a detailed agenda ahead of time.
- More flexibility. Once we have everyone together, we may discover unexpected topics that are of great interest and importance. With a dynamic agenda, we can capture the moment and maximize the value of the conference.
- Spontaneous conversations. Often the most valuable parts of a conference are the informal conversations that happen between people in different teams or roles, who don’t normally work together. People get to know each other, exchange knowledge, and build trust. The open space format encourages this.
If the purpose of a conference is to collaborate and communicate, then an unconference will often fulfill the same purpose in a more simple, fun, and effective way!What are the potential downsides?
If you have a specific topic that you want people to talk about, or specific decisions that need to be made, then this format might not be ideal (or you’ll at least need to tweak it). Because this type of conference is entirely participant driven, so they choose what they want to talk about, and that might not match what you want. As organizer you only set the overall theme and then let go.
So the question is: To what extent do you really need to control the conversation, and to what extent do you trust people to make best use of their time? If you aren’t sure, try letting go of control just once to see what happens. You’ll probably be surprised!What? Is there no structure at all?
Actually there is some structure. But bare-bones compared to how typical conferences work.
The organizer defines a Theme. For example “How we will we make this project super-awesome” or “What are our biggest challenges and what will we do about them” or “How does version 2.0 of our company look like?”.
The theme is super-important, because it will attract the right people to the event (and detract the wrong people). So make sure participation is optional. Once you have an inspiring theme, an experienced facilitator, and the right people in the room, the event will almost surely be a success!
The organizers also define a High level structure. Usually follows this pattern:
- Part 1: Intro & agenda creation.
- Everything gathers up (typically in a ring), facilitator goes through the theme of the day and the driving principles for this way of doing conferences.
- Then people identify topics and work together to allocate them to the different breakout slots. A “topic” could be just about anything – a discussion, a question, a presentation, a demo, a rant, a walk in the park, a pair-programming session, or whatever.
- Part 2: Breakouts.
- The room has a few breakout locations, each with a flip chart and some chairs. The schedule shows which topic is happening where and when. Typically 45-minute or 60-minute slots.
- Everyone chooses where to go, based on Law of 2 Feet: “If you aren’t learning or contributing or having fun where you stand now, use your two feet and go somewhere where you can learn or contribute or have fun”.
- People can roam around freely, and don’t have to stick with the scheduled breakout sessions. Spontaneous conversations can happen by the coffee machine or on the balcony. Breakouts don’t have to stay on topic, participants are free to discuss whatever they want to discuss.
- The time box is not strict. Sometimes a conversation will be over in 20 minutes, sometimes people will want to continue for another hour. Law of 2 Feet overrides everything during the breakouts, so the schedule is not a rule, it’s just a guide to help you figure out where to direct your 2 feet.
- Each topic has a host, who captures actions/decisions/insights (if any). Typically the person who suggested the topic, but anyone could take on the role, it’s pretty informal.
- Part 3: Gathering and sharing.
- Whole group gathers up again. Participants are invited to share any actions/decision/insights/questions that came out of their breakout sessions.
- It’s perfectly OK if your breakout sessions didn’t come up with anything concrete. Often the conversations and personal connections are valuable enough.
- Any other whole-group topics are addressed (such as decisions that affect everyone).
The organizer may add additional elements before the intro, such as inspirational speakers to provide context or knowledge relevant to the them. The organizer may also add elements to the third part (the gathering) for example to capture decisions in a more formal way. Sometimes there will be additional gatherings, for example after lunch (to harvest outcomes from the morning).
But Part 2 (the breakouts) is free of disruptions and the facilitator meddles as little as possible.Law of 2 feet
I’ve already mentioned the Law 2 feet, but I’m giving it a section of it’s own because it’s super-important. It’s the one and only rule of Open Space and Unconferences.
“If you aren’t contributing or learning or having fun where you are now, use your two feet.”
This basically means we trust people to take responsibility and make the best use of their time. If the organizer and all participants keep this in mind, just about any question or problem will sort itself out.How does an unconference look?
Here are some typical scenes:
If you need help organizing one, feel free reach out to firstname.lastname@example.org. Several of us have quite a lot of experience doing these things.
“Start executing and worry less about planning.” QA Consultant
This statement appeared on a recent feedback form after a BERTEIG learning event. It summarized a Quality Assurance Consultant’s learning from the CSM training they attended.
This statement so accurately summarizes one of the key principles of agile methodology which is to do minimal planning and review often. It doesn’t mean “No Planning” it just means different kinds of planning and the willingness to jump quickly into action.
Mishkin published an article on this topic in 2015 and it is re-posted here now because it is still so relevant today.
Agile Planning in a Nutshell
By Mishkin Berteig
Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans. However, many teams desire a long-term plan. This can be thought of as a roadmap or schedule or a release plan. Agile planning helps us build and maintain long-term plans.Agile Planning Process
The steps to do this are actually very simple:
- Write down all the work to be done. In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
- Do some estimation of the work items. Many Agile estimation techniques exist including Planning Poker, The Bucket System, Dot Voting, T-Shirt Sizes. These tools can be applied to many types of estimation. There are three kinds of estimation that are important for Agile Planning:
- Estimating relative business value. Usually done with the business people including customers and users.
- Estimating relative effort. Usually done by the Agile team that will deliver the work.
- Estimating team capacity. Also done by the Agile team (this is sometimes called “velocity”).
- Create the long-term plan. Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work. (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.) Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.
Agile planning allows a team to update estimates at any time. Therefore, the techniques used above should not be thought of as a strict sequence. Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated. Scrum refers to this ongoing process at “Product Backlog Refinement”.Principles of Agile Planning
In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:
- Speed over accuracy. We don’t want to waste time on planning! Planning in and of itself does not deliver value. Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
- Collaborative techniques. We don’t want to be able to blame individuals if something goes wrong. Instead, we create safe estimation and planning techniques. Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
- Relative units. We don’t try to estimate and plan based on “real” units such as dollars or hours. Instead, we use ordering, relative estimation and other relative techniques to compare between options. Humans are bad at estimating in absolute units. We are much better at relative estimation and planning.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Agile Advice: Start Executing With Little Planning appeared first on Agile Advice.
“It usually takes about 36 months to bring a new TV platform to market but we had a minimally viable product in 8-10 months and brought the full product to market in 18 months. SAFe helped our relatively small team build and run a world-class product and guided us when in doubt, showing us the way toward Agile product development flow.”
—Simon Berg, Agile Program Manager, Swisscom Entertainment Projects
Congratulations to Swisscom for developing an award-winning IPTV product, and for doing it in half the usual time-frame. Swisscom’s SAFe story shows what high levels of collaboration between business and IT can accomplish.
When Swisscom initiated plans to bring a new IPTV offering to the market, they knew they had to find a way to get to MVP ahead their competiton who was building a similar product. Coming from a “PMI-style, waterfall, multi-project environment that was transitioning into a home-grown, scaled Scrum approach,” they ultimately turned to SAFe to scale Agile in earnest. PI Planning meetings were new to Swisscom, and when they saw how the event brought together disparate teams that had never before worked with each other, they understood the power of that event to align those diverse stakeholders in a shared vision.
After a year and a half of incrementally adopting SAFe, the results were impressive:
• Swisscom brought TV 2.0 to market in 18 months, where it would normally take 36 months
• They decreased the time from code-ready to mass rollout from 9-12 months to six weeks or less
• Testing now requires just three people, instead of dozens
• Sales and customer satisfaction scores are strong
Perhaps most telling, the product won an award for “Best multi-screen experience,” an honor not usually bestowed on telecommunications companies. Now PI Planning has become standard practice, and other product units have taken interest in SAFe. It’s kind of cool when you realize that Swisscom took their first steps in technology in 1852 when they set up the Swiss telegraph network. Read their full story here.
Many thanks to Simon Berg, Agile Program Manager, Swisscom Entertainment Projects, for sharing Swisscom’s story.
Agile Estimation is an easy concept to understand, but where the rubber meets the road and legacy artifacts such as LOE (level of effort), utilization reports, and other artifacts come into play and confuse is the issue. Questions like, “should we estimate in hours?” and “how do I convert t-shirt sizes to points?” arise. It’s important for an organization to come to a common way to estimate, especially as we move up the governance model from team to program to portfolio.
There are many studies that show estimations are valid in the short-term and they are undependable in the long-term. Additionally, when reviewing any value stream like a software delivery lifecycle, utilization takes a back seat to throughput.
I’m not going to get into the many types of Agile estimation. I will however provide guidance and a standard used among my colleagues and I at LeadingAgile.Epic Estimation
Epics are coarse grained items that we want to build into our product or process. I prefer Epics fit in a release but they can span releases. Epics should be in the one to three month time frame. T-shirt sizing of Epics would be:
S – 1 Sprint 
M – 2 to 4 Sprints
L – 5 to 6 Sprints
Larger that 6 sprints and the Epic should be broken down
 Sprint or iteration lasting 2 weeksFeature Estimation
Features fit inside a release. We need to plan out a release. To do adequate release planning we feature map. The features are sized and prioritized to determine how they lay out over our sprints. Features should be estimated in weeks, so I suggest a one to five week time frame.
Avoid using points on features. Once user stories are broken down, and story points applied, roll up the story points to the feature level. As a result, this will give you the truest “Feature complete percentage” as the team completes user stories in the feature.
If you have a team that is very experienced and has a lot of referential stories, then using story points at the feature level can be acceptable. If this is the case, I suggest you update the points as the user stories are flushed out.User Story Estimation
User stories should be broken down until they are one to three days in size. New teams may have a difficult time with this, but it should be the goal of the product owner team and the delivery team to work towards this goal.
Consequently, story points should be used to estimate stories.New Agile Teams
As a part of sprint planning, new teams should perform a task breakdown. During sprint planning, each story is broken into tasks to be performed; database update, java interface needs to be updated, update unit level tests, etc. These tasks are assigned in hours.
Each task should be kept under eight hours so we can see a smoother sprint burndown each day. Anything larger doesn’t provide visibility to the team. Teams that are doing task hour breakdown will use an hours sprint burndown. Teams that don’t break their tasks into hours would use a story point sprint burndown. Some tool vendors may only support one version of the burndown per instance of the tool. Therefore this should be investigated prior to determining how the team will manage it’s sprints.Agile Estimation Flow
Jerry Doucett is now offering consulting in implementing SAFe 4.0, as well as teaching the following courses and workshops:
1) “Leading SAFe 4.0” course for the SAFe Agilist (SA certification)
2) “SAFe Product Manager – Product Owner” workshop (SPMPO certification)
3) “SAFe 4.0 for Teams” course for the SAFe Practitioner (SP certification).
Please reach out to Jerry by email or on LinkedIn if you have any questions about SAFe or about scaling Agility.
The next SAFe class is “Leading SAFe 4.0” on September 08 and 09. Please see WorldMindware.com for more information including registration.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Announcement: 4 New Steams of SAFe courses offered appeared first on Agile Advice.
Co-located teams are more effective communicators and can sometimes experience increased productivity by up to 60% if situated together in the same room. More simply stated, the greater the dispersion factor, the greater the challenge of collaboration. Note that time zones are often considered the largest dispersion factor and can have a greater impact than geography.
Although it is strongly recommended that teams be co-located, it is not mandatory to success. In fact, certain Agile practices have factors, tools and techniques inherent to them to help bridge some of the shortcomings of increased dispersion, such as a higher reliance on frequent collaboration and communication. But to be clear, they do not replace the value of face-to-face conversation, they are merely a crutch to not having it. (Senior Agile Coach Jerry Doucett)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quote: The Greater the dispersion, the greater the challenges appeared first on Agile Advice.
The next time you’re at an art show or art gallery of any kind, walk up to an artist and ask them to install an electrical outlet in the wall on which their painting is displayed.
After ignoring the inevitable look of bewilderment and snarky response, grab some tools and start hacking the wall apart. Tell the artist that you just need an outlet here so you can recharge your phone.
Be sure to ask them to help.
I’m not 100% certain how this will end, but I can imagine it will involve security guards, police and possibly handcuffs.
As ridiculous as this scenario sounds, though, I feel like this is what I’ve been doing with Docker for the last few months.I wanted to access my app via the container’s IP address.
When using the default “bridge” network, a docker container has it’s own IP address. This can be viewed via the “docker inspect <container name>” command.
That being the case, it would make sense to access the app via that IP address, right?
I thought it made sense, and I expected to be able to use the containers IP address.
So, I dug into the documentation.
I asked on twitter and in various slack communities.
Finally, I asked on the Docker forums. And the response I got?
Basically, a big “nope” and “don’t do that.”
But I wasn’t happy with that answer.
I continued to suggest that it should work this way, even though it doesn’t.
Sure, it may be possible on linux … or with kubernetes… or some other strange mechanism that I’m not aware of, yet.
It took a while to sink in. Eventually, I realized what the real problem was, though.I shouldn’t even be trying to do this.
After a few hours of … “conversation” … with my friend Fred, via the WatchMeCode community slack, I finally started to understand that my expectations of Docker were wrong.
I use a lot of of virtual machines to host services that I don’t want on my laptop directly. Things like Oracle, SQL Server, an LDAP server, etc.
Virtual machines are great at handling these.
Lately, though, I’ve been moving some of these services to Docker. RabbitMQ, MongoDB and my Oracle XE installation are all in Docker containers, for example.
Life is great when I publish the needed ports from the container through my localhost. Everything works peachy.
My experience with virtual machines clouded my Docker expectations, though.
I saw that Docker was technically running on top of a virtual machine, and I immediately went into a virtual machine mentality and expectation set.
But here’s the thing…A Docker container is not a virtual machine.
Yes, it may technically be running on a virtual machine, but that is an implementation detail – hidden behind the scenes – not a feature to be used.
An application hosted in a Docker container is a “virtualized” (containerized) application, not a virtual machine.
Yes, you can find Docker images that include a full linux distribution in them.
These distributions are there to support the application that is contained within, however. They are not to be executed as if they were a full, general purpose virtual machine.This perspective matters, because it sets the expectations for a containerized app.
Imagine for a moment, that you have two node / express apps that both use port 3333.
What happens when you try to run both of them on the same machine?
You get a big fat error, saying the port is already in use.
Now, does it matter that the application is hosted in a Docker container?
Not really – at least, not from the perspective of the host machine when you try to bind port 3333 to more than one container.
You can’t run two apps on the same port of the same IP address. Not with any app on your machine directly, and not with Docker.
And why, you might ask? Because …A Docker container is application virtualization.
And application virtualization is not the same as building a complete virtual machine to run a single service.
A Docker container happens to contain everything that the application needs, to run. But the intent and behavior of that container is to run the application on behalf of your host machine.
It’s a black box that allows you to cleanly separate applications that need different versions of the same dependency.
It gives you the ability to stop and start a server or service as if it were running on your computer directly, without having it installed or configured on your computer.
Docker’s job is to let you sandbox different apps in a system, so they don’t clobber each other’s configuration.A Docker container is art hanging on a wall.
Art occupies a physical space. And due to those pesky laws of physics, one piece of art will prevent another from occupying the same space.
This was the mistake I made in my view of Docker.
I expected each Docker container to be a separate art gallery. In reality, each container is a piece of art hanging on the wall.
I should have been asking the artist about the intent or meaning of their painting, enjoying it for what it is.
Instead, I wanted to know why there wasn’t an outlet in the wall. I wanted the artist to help me with construction work – something that they may know nothing about.
I decided to try and tear up the wall on which the art was mounted, because I thought the wall was a fundamental part of the installation.
And the installation, as I saw it, wasn’t living up to my very inaccurate expectations.Tweet
There must be a consistent commitment and engagement from all parties in the organization towards adopting the Scrum framework, Agile methods, and thinking. The initiative must be an open, collaborative experience and there must be complete understanding and alignment by all parties in assuming the risks and rewards as well as sharing in the effort. This includes not only business partners and their IT counterparts, but their leadership as well as all of the people and teams supporting an Agile initiative. (Senior Agile Coach Jerry Doucett)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quote: Consistent Commitment is Key To Team Success appeared first on Agile Advice.
Brain Rules: 12 Principles for Surviving and Thriving at Work, Home and School by John Medina – A description of rules with how our brain works and how we learn. Our visual senses tend to trump our sense of smell. We need sleep to restore our energy and to help us concentrate. Spaced repetition is important, but assigning meaning to new words and concepts are also important to learning. Since I’m fascinated with learning and how the brain works, I’ll add this to my reading list.
Getting Things Done: The Art of Stress-free Productivity by
David Allen – Although I never read the book, I felt like I follow a similarly described organisation system. The GTD method is almost like a cult, but requires a lot of discipline for it. Unlike keeping a single list of things to do, they have a systemised variant for keeping long-lived projects and ways of managing tasks to help you focus on getting through actions. Probably a good book if you want to focus more on breaking things done into smaller steps.
The Checklist Manifesto: How to Get Things Right by Atul Gawande – With lots of examples from the healthcare industry, a reminder that useful checklists can help us avoid making simple mistakes. For me, the idea of standardised work (a lean concept) already covers this. I agree with this idea in principle, but I’m not so sure the book covers the negative side effects of checklists as well (people getting lazy) or alternatives to checklist (automation and designing against error/failure demand to be begin with).
Connect: The Secret LinkedIn Playbook to Generate Leads, Build Relationships, and Dramatically Increase Your Sales by Josh Turner – Either a terrible summary or a terrible book, this blink gave advice about how to use LinkedIn to build a community. Although the advice isn’t terrible, it’s not terribly new, and I didn’t really find any insights. I definitely won’t be getting a copy of this book.
Start With Why: How Great Leaders Inspire Everyone To Take Action by Simon Sinek – A nice summary of leadership styles and rather than focusing on how something should be done, and the what, is starting with the why. I liked the explanation of the Golden Circle with three concentric circles draw within each other, with the Why being the starting point that leads to the How that ends in the What. It’s a good reminder about effective delegation and how powerful the Why motivator can be. I’ve added this book to my reading list to.
This is a great introduction to Cloud Concepts!Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!