“As a manager, when someone on a team has an obstacle, your first question should be, ‘how can I remove that obstacle?’ ”
This tip and more is introduced in this video.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The new Scrum Guide, released recently, has the five Scrum values added back!!!
Many here voted on uservoice.com – and our community had an impact!!!
Congratulations to you all! Check out the new Scrum Guide at http://www.scrumguides.org/ – the paragraph on values is close to the start of the guide.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Learning the Value of Transparency Through Agile
by Valerie Senyk
I am intrigued by the principle of transparency which my employer, BERTEIG, models so beautifully.
When we have company (team) meetings, the owners practice complete transparency in regards to company finances, including profits and salaries. As we discuss various agenda items in our meetings, we are encouraged to be completely frank in order to make good team decisions. If personal issues are affecting a team member, he or she is respectfully listened to. If an employee needs time off, the need is not questioned. These are just some concrete examples of BERTEIG’s transparency.
Yet I don’t know how transparency is understood and practiced in other Agile environments or teams.
In the official Scrum website authored by Jeff Sutherland and Ken Schwaber (www.scrumguides.org), transparency is described as one of the three “pillars” of Scrum Values:
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.
Successful use of Scrum depends on people becoming more proficient in living these five values….The Scrum Team members have courage to do the right thing and work on tough problems….The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.
From the above description, one understands that transparency exists along with other values such as commitment and courage, and that it is one of the necessary ingredients to building trust in a team.
Yet trust seems to be a deficient commodity in our times. There are so many reasons in everyday life to not trust, that trusting others becomes a challenge and perhaps even an obstacle.
The above site goes on to describe what is meant by transparency in a specific Scrum IT environment, which I believe is applicable in diverse organizations:
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
Those performing the work and those accepting the work product must share a common definition of ‘Done’
Further in the same site there is a heading for “Artifact Transparency” which gets a little closer to the bone of understanding transparency’s importance:Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts…To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.
The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.
What the above description does not include is corporate or personal transparency as practiced at BERTEIG. Transparency in an organization at the level the authors are talking about is impossible as long as a hierarchy exists whereby ascending the corporate ladder needs to be on the proven merits of things that a person has done instead of their attitude and willingness to walk a new path.
However, the above does make it clear that decisions will be sound, risk will be controlled, and value is optimized when transparency is practiced.
Overall, how do these ideas co-exist with the general Agile framework? From an article by Sameh Zeid on the Scrum Alliance website, he discusses six ways a product owner can increase transparency, then writes:
…without transparency we may not succeed in implementing Agile — and even if we can, the project can revert to command and control. Transparency implementation starts by leadership as represented by the product owner.
There is a plethora of resources that one can access regarding Agile values and how to make it work. I believe transparency is a value that requires courage to begin with – courage which is facilitated by having an Agile culture.
BERTEIG is one company I know of that whole-heartedly practices transparency – – In fact, that element of “heart” may be exactly what’s needed in many organizations. It seems transparency can truly occur when there is caring between employer and employee.
How do you experience transparency, or lack of it, in your workplace?
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Labor Day has been celebrated for more than 122 years. The holiday is “dedicated to the social and economic achievements of American workers. It constitutes a yearly national tribute to the contributions workers have made to the strength, prosperity, and well-being of our country”. Since then the labor force in the United States has shifted dramatically, and like many of our national holidays, the purpose and intent of the day has become obscured by modern traditions and fanfare. For most of us, Labor Day is a farewell celebration for summer, the kick-off of a new school year, and the start of the football season. It means backyard cookouts, picnics in the park, parades, and more.
I’m not sure I can think of a single Labor Day when I stopped to think about the “contribution workers make to the strength, prosperity, and well-being of our country.” So today, it seemed appropriate to share a few thoughts on how, if we truly want to honor the contribution of our workers, it shouldn’t be a once-a-year occurrence. It should be an everyday occurrence. It should be manifested in our daily interactions with our co-workers, peers, leaders, managers and subordinates. It should be part of the DNA of our team and company cultures, because it is indeed the workers in our companies that serve our customers and create the backbone of our company’s success and our nation’s economy. Paying tribute to our workers should be a core value of our company.
Paying tribute to our workers should be a core value of any company, not just once a year.
Click To Tweet
As I think about the SolutionsIQ mission and the work we do with our clients, I reflect on Agile values and principles, qualities of outstanding organizations, and characteristics of admired leaders. Here are a few points that resonate for me, and I hope they may inspire you to make the tribute of Labor Day a part of everyday.
- Transcendent Purpose – Start with Why
If we want a company with strength and prosperity, we need an engaged workforce. People that are passionate about what they do and know it makes a difference. A key factor in successful organizations and with impactful leaders is a focus on WHY, the purpose behind how we do things and what we actually do within our organizations. Honor the workers in your organization with the gift of purpose.
- Sustainable Pace – Agile Principle
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” (3) I could write an entire article referencing research that touts the benefits of focus, WIP limits, and slack time in the work day. The fact is that our ever increasingly technologically complex society is crushing us with stimuli and our brains just can’t handle it. We fall victims to a rat race where folks believe it’s a badge of honor to work on 13 projects all at the same time and be “needed” 60-80 hours a week. But to what end? Children that don’t really know their parents, divorces, aging parents that just want to see their child, bad products, and poor customer service? Is it really worth it? Be a leader that models sustainable pace (a challenge I personally have), and give the gift of slack time in schedules. Talk about a way to improve the well-being of our country – wow!
- Bring Humanity to the Workplace
If you watch “RSA Animate: Dan Pink – Drive: The Surprising Truth About what Motivates Us“, you’ll see that he’s talking about more than motivation. He says we should treat people like people, not just “slower, smaller, better-smelling horses.”
Pink’s book “Drive” is really about the core of bringing humanity back to the workplace. Valuing our people, not treating them like infinitely expendable resources. Celebrate this every day, and Labor Day isn’t just a holiday for you – it’s a way of life.
In Agile, recognizing the people who keep the business going isn’t a once-a-year event.
Click To Tweet
Like this? You’ll love Agile Eats
Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!
Derek Whether is definitely on to something. He’s recently posted an article on his blog poking fun at a common cultural blunder people seem to make when they judge or criticize someone for “not being agile enough” or “not doing Scrum right.”
What is it about our culture that leads us to criticize?
He questions why do we tend look to others as though they are doing something wrong and the “agile police” or “vegetarian police” are going to show up and make arrests.
Instead of asserting the law, perhaps sometimes we can become advocates or ambassadors instead.
He makes a good point and even suggests an amendment to the Agile Manifesto. Take a peek. It’s certainly a 13th principle I’d agree to.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
We just released a new LeanKit iOS mobile app that provides a faster, more reliable mobile experience....
In June, BERTEIG hosted the first Certified Agile Leadership (CAL1) training in Canada, led by Michael Sahota.
Here are some images from the event!
Click here to register for the next CAL1 TrainingScrum and Agile training sessions on WorldMindware.comPlease share!
The post Announcement: First Certified Agile Leadership Training In Canada! appeared first on Agile Advice.
At the end of the day your goal should not be to become Agile or Scrum savvy. Instead your real goals and outcomes should align with achieving the key benefits of Agility, and with what Scrum offers. These should include (but are not limited to) increased customer satisfaction, faster delivery of value, improved feedback loops, adopting a continuous improvement mindset, improved employee morale and increased employee retention. Scrum is just one of the many tools or approaches you may choose to get there, but it is certainly an important one to consider if these outcomes align with your goals.
For Scrum to be truly successful at your organization, you must dramatically transform your very culture and business approach. To be clear, this is not easy to do but the rewards are well worth the effort. By embracing such a transformation, the adopted change in behaviour, beliefs and practices should result in a more successful Scrum experience and a higher degree of satisfaction for both your customers and employees.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quote: Transform Culture & Business Approach appeared first on Agile Advice.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Want increased success with your Agile Transformation? Here are the 10 most important Navigation Secrets for Execs and Coaches. In this post, I share key lessons I have learn over years of industry experience. This presentation came out of a webinar I ran with Maria Matarelli to help generate interest in execs and coaches for my […]
If you’ve been following the releases of the Scanner for MsBuild and the C# plugin over the last two years, you must have noticed that we significantly improved our integration with the build tool and at the same time added a lot of new rules. Also, we introduced SonarLint for Visual Studio, a new tool to analyze code inside the IDE. With these steps completed we are deprecating the SonarQube ReSharper plugin to be able to provide a consistent, high-level experience among our tools.
In the last couple years we’ve worked in close collaboration with Microsoft to make our products fit easily into the .NET ecosystem. The goal of the collaboration was two-fold:
- integrate the SonarQube Scanner for MsBuild seamlessly into the build process
- develop the Connected Mode in SonarLint for Visual Studio to propagate analysis settings from SonarQube to Visual Studio.
The improvements to the SonarQube Scanner for MsBuild resulted in pre- and post-build command line steps that respectively download settings from, and upload analysis results to your SonarQube server. And in between these steps, your MsBuild step doesn’t need to be changed at all. In addition to the SonarLint Connected Mode, we achieved our main goal of showing the exact same issues inside the IDE as you’d see on the SonarQube server.
From a technology perspective, both of these integration pieces are highly dependent on the new .NET compiler platform, Roslyn. Additionally, we’ve put a great deal of effort into implementing rules based on Roslyn. From SonarLint for Visual Studio version 1.0, which was released on July 20, 2015 with 76 rules, we’ve increased our C# offerings to 173 rules. Our C# rule engine, the SonarAnalyzer for C#, is the underlying rule engine in both SonarLint for Visual Studio and the C# plugin. So no matter where you’re running the analysis, you benefit from the new rules. Many of the rules might have already been familiar to you, because we prioritized the implementation of ReSharper-like rules. We went through all the C# warning rules that are enabled by default in ReSharper and in the end we found that more than 80% of them are now covered by the SonarAnalyzer for C#.
We even went a step further, and made the SonarQube Roslyn SDK to provide a way to integrate your Roslyn-based rules into the analysis process both inside the IDE and with the Scanner for MSBuild. However, we can’t provide the same consistent user experience with ReSharper because it’s not based on Roslyn. ReSharper analysis in the build process isn’t MSBuild-based; it requires a dedicated command line tool. And inside Visual Studio, ReSharper is a completely separate analysis tool, so there’s no way to make the Connected Mode support ReSharper settings. As a result, we decided to deprecate the ReSharper plugin and move it to the community maintained extensions.
To sum up, in order to best focus our efforts on valuable features and provide you with the best user experience, we decided to drop support for the ReSharper plugin. “Less is More” is our frequently repeated mantra at SonarSource. With this step, you’ll have fewer tools to worry about, and a more consistent experience across our products. Additionally, you’ll benefit from our quick release cycles, and get updates every months or so. Recently, we’ve focused our efforts on advanced bug detection rules. Did you know that our brand new symbolic execution engine found a NullReferenceException bug in Roslyn?
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!
“Therefore, the best criterion for choosing what to keep and what to discard is whether keeping it will make you happy, whether it will bring you joy.”
― Marie Kondo
Marie Kondo changed my life. Her approach to purging my home of things that didn’t make me happy proved to be the most effective means of simplifying my life I’ve encountered. By focusing on feelings, she took all the doubt, stress, and guilt out of culling the contents of my closet, kitchen, electronics, and toiletries.
Minimalism or simplicity is not a new idea, but her contribution is to suggest that we use our feelings as the primary deciding factor, which in practice worked much better for me than other methods. The result is that I decluttered far more efficiently and effectively than ever before, eliminating over 75% of my possessions without worrying that I was making a mistake. It worked because the purpose of my things is to give me comfort and security and my feelings about a thing are an excellent reflection of its ability to provide those two things.
I wonder if the same principle could be applied to product design?
The Kanbanery ideas backlog contains hundreds of items, collected over years of brainstorming, competitive intelligence gathering (once we had competitors), and customer feedback. I wrote last week about how my attitudes toward customer feature requests have changed over the years. Some of the ideas come from competitors and are things that we won’t do on principle (see last week’s post on principle-driven design ). Requests from clients that have sat on the list for over five years have been passed over in hundreds of queue replenishment sessions for a reason. They serve the same function as that ugly sweater your mom bought you does in your closet, guilt. It’s time to admit to ourselves that we’ll never do it because we don’t want to.
“By facing your things, you’re facing yourself,” Marie Kondo says. “It will make you happy and everyone around you happy.” That’s an idea that fits wonderfully with my ideas about Principle-Driven Design. A team that culls a backlog together, faces their demons together and grows together. Together they can learn what makes them happy to come to work.
“The process of assessing how you feel about the things you own, identifying those that have fulfilled their purpose, expressing your gratitude, and bidding them farewell, is really about examining your inner self, a rite of passage to a new life.”
― Marie Kondo
Just as taking stock of our personal possessions and what they mean to us can help us to understand who we are now and how we see our future, applying those same techniques to a backlog as a team helps the team to better understand who they are now and where they see the product going in the future. The product vision they had in the past was valid, and useful. Even deciding not to do something teaches us something about ourselves and our values. It inspired us once, but parts of it no longer do. Let them go.
“But when we really delve into the reasons for why we can’t let something go, there are only two: an attachment to the past or a fear for the future.”
― Marie Kondo
Isn’t this so true of an old backlog? “It seemed like a good idea at the time, so it must have been.” or “But we might need this some day!” are two of the most common excuses for keeping old ideas in a bloated backlog.
“The space in which we live should be for the person we are becoming now, not for the person we were in the past.”
― Marie Kondo
We had a clear vision of where we wanted the product to go, but we’ve pivoted or we’ve learned through iterative releases and user feedback and research. Our vision has changed. Shouldn’t our backlog?
A scrum team might say that this is solely the prominence of the Product Owner. In Scrum terms, that’s true. But an old backlog suggests an experienced team. One of the great things about the tech world is that it’s largely inhabited by intelligent, enthusiastic people. After months or years of working on a product, the team becomes heavily invested in it, and they have very valid ideas of their own. If those ideas differ from the Product Owner’s, there’s no better time to find out and talk about it than now. In the process, the team can learn what inspires them and forge a shared vision.
Just go through that old backlog as you would a pile of clothes from the deepest depths of your closet. Sort them by type, however, makes sense. For example, bugs, UI enhancements, administrative features, reporting features, onboarding improvements, core features, etc. The go through each group of features, looking at each one carefully and asking if it inspires the team. How do they feel about it? Maybe make a deck of cards for each member with feelings like “excited”, “ambivalent”, “scared”, “guilty”, and “amused” and use them like planning poker. Discuss outliers. And most importantly, discard all those ideas that don’t inspire positive feelings.
As you’re doing it, think about each idea from different points of view. How do you feel about it in general? What’s the first feeling that comes to you? How would you feel if that feature were already done? If you could implement it as easily as flicking a switch, would that make you feel good, or not? If a feature scares you and having it done would scare you, too, discard it. But if it scares you but having it done excites you, that’s a challenge worth doing.
If your backlog is in Kanbanery, you can export it as a CSV file and work with it in a spreadsheet. If it’s in your first column, you can move everything that doesn’t inspire positive feelings to the icebox if you’re worried about making a mistake. I suspect you’ll soon feel relieved to have those little nuggets of negativity out of sight and will happily go back later and delete them.
Just be sure as you do to thank them for the inspiration they once provided. Gratitude lies at the core of happiness, and taking a moment to acknowledge the lessons those ideas have provided before consigning them to eternal nullness makes that process cathartic rather than agonizing.
If you try this, please let me know how it goes. If you think I’m nuts, you can tell me that, too.
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.
“Don’t ‘over control’ like a novice pilot. Stay loose enough from the flow that you can observe...