Skip to content

Feed aggregator

Why Scrum masters shouldn’t be the one solving all impediments

Ben Linders - Mon, 03/21/2016 - 14:26
Who should be handling and solving impediments? Should it be the Scrum master? The team as a whole! Their agile coach? I prefer that team members recognize and solve impediments themselves. For most of them they don't need a Scrum master or coach. So if they see a problem, I expect team members to take action and solve it. Continue reading →
Categories: Blogs

Back Home at Net Objectives: What I’ve Learned

NetObjectives - Mon, 03/21/2016 - 13:22
It’s great to be back home at Net Objectives. Al Shalloway has built something special and I’m especially excited to be a part of his growing team once again. Whereas some consulting companies in the Lean-Agile space can implement a framework, Al and his experienced associates at Net Objectives have figured out a transformation process: one that applies decision patterns to an organization that...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

"Simple to Say But Hard to Do"? or "Saying Simplistically What is Hard to Do"?

NetObjectives - Sun, 03/20/2016 - 17:06
I have been doing “Agile” for 17+ years consciously and on and off for 30+ years if I look at times in past I created one-off Agile practices without knowing what Agile was (e.g., the time I did automated acceptance testing in 1984).  Almost from the beginning of Agile I have heard people defend it by saying “simple to say hard to do” as if that meant the failures in adoption didn’t reflect badly...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Influential Agile Leader on Projects at Work

Johanna Rothman - Fri, 03/18/2016 - 23:09

I spoke with Dave Prior on a podcast for Projects at Work. The podcast is titled “Influential Agile Leader.” We spoke about how leaders need to practice coaching and influence, and how to use experiential approaches to helping people learn how.

You can learn with Gil Broza and me at the Influential Agile Leader. We are leading sessions in Boston April 6-7 and in London May 4-5. We will close registration March 24, so register now.

Categories: Blogs

5 Sure-Fire Ways to Breathe New Life into your Content Strategy

About SCRUM - Hamid Shojaee Axosoft - Fri, 03/18/2016 - 00:04

Content strategy is no longer sexy. What used to be the little black dress of marketing has become that maxi dress you wore to the beach three summers ago and is now hanging in the back of your closet.

black dress

But, just like the memories you have from that beach vacation, you hang on to it because you know it’s a good go-to outfit for your next beach vacation—plain and simple, it works.

Content strategy is something that pretty much all companies and organizations use in order to foster new relationships, keep current clients or customers informed and then create loyalty.

Anyways, spring is here so it’s time to dig into the back of your marketing closet, grab that maxi dress and turn it into the stunner it once ways. Here are 5 ways you can breathe new life into your content strategy—immediately. Beach vacation optional.

1. Look at your content like a new relationship

New relationships are super fun. Whether they are new friendships, blossoming romances or even a new mentorship. They create excitement because we are unsure where they are leading us, but we feel they are leading us somewhere good.

We get comfortable after spending some time together, which is a good thing. But, we’re no longer infused with that roller coaster free-fall feeling. That’s when it’s time to do an audit.

According to Lawdan Shojaee, CEO of Axosoft, “there are all sorts of ways we create content strategy; you come up with the strategy then constantly iterate on it.” She continues, “if you designate a time to go back, ask questions and investigate to see if the original strategy was successful, you’ll see if the strategy did what it was meant to do or if it went astray.”

Comb through your past blog posts, social posts, white papers and check your metrics. Did your messages reach the folks you wrote them for? Yes? Yay! No? Don’t freak out. Just start over. You did it once, you can do it again.

2. Form the right relationships for you

Figure out who you want to talk to. Who are your customers, your fans, your tribe? Who needs what you’re offering? More than likely, a couple years ago, you identified personas—a general biopic of these folks. They probably read like this: “Ted is 26 and lives in Wisconsin. His challenge is that his project management software is just, well, lame and he doesn’t want to use it. He’s looking for something he can bring to his boss that will make him look like the winner he is.”

Because someone wrote these for your organization or team a couple years ago, it’s probably time to take another look. Revisit Ted. Does he still have those same needs? Have new types of folks emerged? Maybe there’s Susan now, who is 32 and needs a development tool that will help her visualize her team’s progress?

According to Shojaee, you really need to understand where your personas are within the purchasing cycle. “Figure out who they are and what your product means to them. Look at who buys, who makes the phone calls and who is in the meetings.”

She recommends identifying every single person that takes that buying journey with you. Because, “they are not always the people who you think they are. They could be the accountant who will be on that initial call because they need to know the costs; project managers or developers,” she says.

Once your initial buying personas are identified, you need to consider another set—those who need content that helps them understand why they need the product. They may not be the same person who wanted the product in the first place. There’s a difference between the consideration and purchaser set.

Got it? Different people need different things from you. And these people change; some need convincing and others need educational resources from you. So check in with them periodically. You may have to rekindle the romance.

3. Get over your paralysis

Stop thinking so much. It’s easy to get overwhelmed by metrics and traffic and the inordinate amount of information you need—or think you need. Sometimes, there’s so much stuff to learn and keep track of, some people just stop doing everything. This is known as “paralysis by analysis” and it’s bad because action is always better than staying stagnant.

“I’m reading a book about General Patton,” says Shojaee. And of course she is because being a CEO requires strategy, stamina and strength—just like military leaders. “There’s a famous quote from him that says something like going into battle half ready, but aggressively, is better than having a perfect plan and going into battle.”

Yes, the data can be overwhelming. But, once you go back and look at your data, you may see that the same number of people have come to your content through Twitter, your newsletter or organic search. Maybe the numbers aren’t that different from one another.

The tendency to overthink and hypothesize and run the numbers again is tempting. However, “if you keep doing this, you will find yourself paralyzed,” says Shojaee.

Don’t fall into this trap and plan as best as you. According to Shojaee, “Quit and start over again. Each time you do it, you’ll get better. Keep doing this until it’s fixed. Push forward. It’s better to do something efficiently and to the best of your ability rather than stewing over the idea of a perfect plan for it.” Forward, march!

4. Change your perspective with a change of venue

The very nature of content is based on delivering interesting “stuff” whether it be in the form of interesting blog posts, instructional videos, straight-forward white papers, witty social quips or fresh infographics. So, what do you do if you’ve been doing it for awhile and you just simply run out of ideas?

You’ve done it all, you think. You are tapped out. You simply cannot write another article about agile methodology or A Day in the Life of a Developer one more time. Is it time to pack it in? NO!

“Go to other people’s blogs, go to talks and see what new vantage points you can glean,” says Shojaee. “Maybe it’s time to write about something completely different. You need to shake up your perspective because you’re so laser focused on one thing,” she explains

“This is why our team at Axosoft is so diversified in a lot of things we do. Switching up habits and thinking patterns is not just fun, it’s necessary.” Shojaee explains that this is why the company sends employees on a trip at their 1-year and 5-year anniversaries.

Sweet! you may say. But, there’s a catch: you have to go somewhere you’ve never been before, and get out of your comfort zone. You have to do research and learn new habits. “This is inherent in the culture of the company,” Shojaee explains. “Changing the way you think affects everything.”

5. Stop everything. Just do it again

So, you’re running your content strategy, loving it, nurturing it, pumping out meaningful content, and just frolicking through wheat fields with it into the sunset. Happily ever after, you may think. Not true. Once you’re comfy cozy, that most likely means it’s time to change something because if you’re that good, it’s time to get even better.

Shojaee is all for taking risks. Because this is how you grow and learn. If you fail, just fail fast.

Now what?

Granted, we’re not a marketing agency, but, I’m the Content Strategist in our marketing department and we work hard to market the Axosoft products and brand. So, we feel comfortable sharing our advice with you! We’d love to hear what your thoughts are on content strategy. What are some tips you’d like to share?

If you’re interested in finding an agile project management software tool that “makes you look like the winner you are,” (Just like Ted, above) check out the features of Axosoft. If you’re Interested in working for a team that nurtures new habits and perspectives, check out our open positions.

Categories: Companies

Agile in a Bag London 2016 Call for Speakers

Scrum Expert - Thu, 03/17/2016 - 17:23
The Agile in a Bag conference will be back in London the Friday 10th of June 2016. It proposes workshops to help you understand how Agile works and interesting presentations explaining Scrum ideas. It is also a great place to network with fellow Agile practitioners in London. The topics of the conference are fundamentals of agile methodologies, tools and best practices, how to apply this knowledge to make your projects successful. The call for talks and workshops for the Agile in a Bag London conference is open until April 2. More information on http://agileinabag.co.uk/
Categories: Communities

Should We Have a WIP Limit For Organizational Change?

Leading Agile - Thu, 03/17/2016 - 12:30

During a recent podcast interview, Russ Pena and I began talking about the impact of change on a product focused organization that is trying to adopt a more agile and innovation-centric mindset.

Our conversation introduced a new topic that has been rattling around in my head since Russ and I spoke. I’m writing this post with the hope that it might generate discussion and help the idea take form.

Talking about the significance of the change is not a new thing. Oceans have been written about how people go through stages of changes, etc. And most of the professional knowledge workers who earn their keep by helping organizations go through agile transformation would probably tell you that the hardest part of the change is almost never the process. Even though many people focus on that, its’ usually the easiest part. The Gordian knot of of transforming to an agile or innovation-centric approach stems from the impact of the cultural change and the shift in value systems.

During the podcast, Russ and I got to talking about how many clients enter into transformation without really knowing what to expect, or  they have some sense of what to expect, but have decided that because their company is “different”, they are going to just throw a switch and change will be adopted throughout every level of the organization out of sheer will.

As we talked through the topic, we started to kick around the idea of coming up with a way to understand the velocity of change the organization was able to absorb, and if so, could we work out a WIP limit for change (or Change in Process limit). While each organization is different, there is going to be a pace at which change can be absorbed, and a tipping point at which it is no longer able to absorb more. When introducing change, a reaction against that change is to be expected. But there is a point at which the strength of the reaction becomes stronger than the driver of the change.

Drawing a parallel to the way a team can only manage a certain amount of work in the system at any given time, an organization may only be able to tolerate a limited amount of change (in various stages) at one time. If that amount is exceeded, and the change becomes too much of an irritant, the organization may resist the change with enough force to cause the change to fail. The question that arose during my discussion with Russ was this;

Can an organization develop an understanding of how much change can be introduced at a given time, without alerting the organizational antibodies who will come to fight off this foreign approach?

For this to be something measurable, we would have to be able to define different changes (or patterns of change) we were going to introduce. We would also need to have a way of weighting them or gauging their potential impact based on both the change being introduced and the specific organization’s likelihood to resist the change.

If we were able to capture all this, it would make sense to try to define a standardized way of assessing an organization’s resistance strength (maybe cultural and/or process fortitude), it’s average reaction time. Or, how quickly does the organization respond with antibodies that will resist the change?

If we had a way of understanding an organization’s cultural and process fortitude, it’s response time, the significance (or weight) of the change being introduced, and some additional metrics or observations on how (in general) organizations begin absorbing and resisting change, then we could arrive at a Change In Process (CIP) limit for introducing transformational changes to an organization.

What are your thoughts on limiting the amount of Change in Process for an organization embarking on their journey with Agile Transformation?

The post Should We Have a WIP Limit For Organizational Change? appeared first on LeadingAgile.

Categories: Blogs

Should We Have a WIP Limit For Organizational Change?

Leading Agile - Thu, 03/17/2016 - 12:30

During a recent podcast interview, Russ Pena and I began talking about the impact of change on a product focused organization that is trying to adopt a more agile and innovation-centric mindset.

Our conversation introduced a new topic that has been rattling around in my head since Russ and I spoke. I’m writing this post with the hope that it might generate discussion and help the idea take form.

Talking about the significance of the change is not a new thing. Oceans have been written about how people go through stages of changes, etc. And most of the professional knowledge workers who earn their keep by helping organizations go through agile transformation would probably tell you that the hardest part of the change is almost never the process. Even though many people focus on that, its’ usually the easiest part. The Gordian knot of of transforming to an agile or innovation-centric approach stems from the impact of the cultural change and the shift in value systems.

During the podcast, Russ and I got to talking about how many clients enter into transformation without really knowing what to expect, or  they have some sense of what to expect, but have decided that because their company is “different”, they are going to just throw a switch and change will be adopted throughout every level of the organization out of sheer will.

As we talked through the topic, we started to kick around the idea of coming up with a way to understand the velocity of change the organization was able to absorb, and if so, could we work out a WIP limit for change (or Change in Process limit). While each organization is different, there is going to be a pace at which change can be absorbed, and a tipping point at which it is no longer able to absorb more. When introducing change, a reaction against that change is to be expected. But there is a point at which the strength of the reaction becomes stronger than the driver of the change.

Drawing a parallel to the way a team can only manage a certain amount of work in the system at any given time, an organization may only be able to tolerate a limited amount of change (in various stages) at one time. If that amount is exceeded, and the change becomes too much of an irritant, the organization may resist the change with enough force to cause the change to fail. The question that arose during my discussion with Russ was this;

Can an organization develop an understanding of how much change can be introduced at a given time, without alerting the organizational antibodies who will come to fight off this foreign approach?

For this to be something measurable, we would have to be able to define different changes (or patterns of change) we were going to introduce. We would also need to have a way of weighting them or gauging their potential impact based on both the change being introduced and the specific organization’s likelihood to resist the change.

If we were able to capture all this, it would make sense to try to define a standardized way of assessing an organization’s resistance strength (maybe cultural and/or process fortitude), it’s average reaction time. Or, how quickly does the organization respond with antibodies that will resist the change?

If we had a way of understanding an organization’s cultural and process fortitude, it’s response time, the significance (or weight) of the change being introduced, and some additional metrics or observations on how (in general) organizations begin absorbing and resisting change, then we could arrive at a Change In Process (CIP) limit for introducing transformational changes to an organization.

What are your thoughts on limiting the amount of Change in Process for an organization embarking on their journey with Agile Transformation?

The post Should We Have a WIP Limit For Organizational Change? appeared first on LeadingAgile.

Categories: Blogs

Introducing Leanban: The 3rd Generation of Lean-Agile for the Team

NetObjectives - Wed, 03/16/2016 - 23:20
Leanban was created as an answer to the following challenges we’ve seen in many organizations: Many of a company’s Agile teams are improperly following the method that they’ve adopted Different teams use different methods making it difficult for people to move from one team to another Teams following different methods often have difficulty working well together There is significant dogma in the...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Become Customer Centric

Scrum Expert - Wed, 03/16/2016 - 22:43
The first principle of Agile manifesto says “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” But, Is our highest priority to delight our customer, or to delight our sponsor. Do we understand who the real customer is and behave accordingly? I’ve often seen Agile teams producing software aimed to delight: another departments within their organization, an external organization hiring their development services, their management or even their Product Owners. But, are those the ones to be delighted by the product in development? I believe that software is awesome when it helps creating awesome experiences to the people the organization is serving. To create those delighting experiences is very important to understand who your real customer is and empathize with him. This session is aimed to create that awareness and to introduce some practical tools that can help creating a “Customer Centric” Agile implementation and culture in organizations.I will start the session by explaining what is customer centricity and how it can become the competitive advantage of your business and a powerful reason for adopting Agile. I’ll continue with simple tips, and practical examples, which attendees can incorporate into your Agile implementation to empower customer delighting. Such as including “moments of truth” in “Personas” and going from “User Stories” to “Customer Stories”The listener will get from this session easy-to-apply tools to equip their Agile implementation an extra focus on their real customer to maximize customer satisfaction and create an important foundation for the [...]
Categories: Communities

LeanKit Provides Two New Reports

Scrum Expert - Wed, 03/16/2016 - 19:01
LeanKit provides a flexible environment where teams practicing different methodologies — such as Kanban, Scrum, Waterfall and everything in between — can work together within the context of the larger enterprise system to deliver value faster. To support the needs of teams practicing Scrum and Scrumban, LeanKit has announced that a burndown report is now available. In addition, for teams using planned finish dates to plan and schedule their work, LeanKit has introduced a new Planned Percent Complete report. The Burndown Chart is a graphical representation of work left to do versus time, teams practicing Scrum and Scrumban use burndown reports to answer the question: “Are we on pace to complete our committed work by the end of this sprint?” The Planned Percent Complete (PPC) chart helps us answer the question: “How accurate are we at planning our work to deliver on our commitments?” This report measures the percentage of work items that are 100% complete on the specified finish date.
Categories: Communities

Hansoft Introduces Favro Agile App

Scrum Expert - Wed, 03/16/2016 - 17:22
Hansoft has introduced the Favro app – its much anticipated segue into the Agile collaboration software space; since raising $10 million in first round funding lead by Spotify investor, Creandum, two years ago. With Favro, Hansoft has created a new cloud-based freemium platform that brings a new level of Agile management practices not only to software engineers but to teams working within sales, support, operations, marketing, legal, finance, logistics, and management. For more than a decade Hansoft has made efficient and innovative tools designed to enhance project management and team collaboration in software development. People depend on Hansoft when building everything from video games to space rockets and satellites. Favro empowers people to create really great things together. An app that is simple enough for everyone to use, yet powerful enough for the complexities of work in today’s world. An app that visualizes work on your laptop, tablet, and smartphone, and lets you choose to use simple or advanced tools; giving you what’s needed to get things done. Labelled as a direct competitor of Trello, Asana and Jira, Favro lets everyone collaborate in their own teams, whatever processes have been agreed on.
Categories: Communities

Trailblazing Women in the Cloud

About SCRUM - Hamid Shojaee Axosoft - Tue, 03/15/2016 - 21:14

These days the stats are well known: women make up more than half of the US labor force but only 30 percent of the jobs in tech, and less than a quarter of leadership positions in tech. With this statistic in mind, you can imagine that women specializing in cloud technologies are few and far between.

Cloud Girls

That’s why five years ago we founded Cloud Girls, a vendor-neutral, not-for-profit community of female technology advocates dedicated to educating themselves, their organizations and their customers about the dynamic cloud ecosystem.

Cloud Girls logo

We explore emerging market and technical trends, advocate best practices/reference architectures and build community consensus. Most importantly, we provide a technical and business support system for our members, who are invited to join based on their engagement in cloud, primarily as sales and engineering experts. In this way, Cloud Girls truly is empowering and fostering the next wave of women in technology.

Creating the “Woman to Watch” Award

As our group has grown and matured, we have encountered and engaged some amazing and talented women working in the cloud—many on the front lines but not in the headlines. So, we decided that we want to recognize and reward them and raise their profile as role models. To do that in 2016, we are giving the first-ever Cloud Girls Rising: A Woman to Watch award.

We believe that women who have put their stake in the ground early around cloud computing are risk takers. Cloud is just starting to become a “safe” technology to explore, and it’s even becoming a little cool.

For the longest time cloud was the “Wild West,” and the women who decided to gamble on it were brave pioneers in uncharted territory. Plenty of evangelizing happens prior to adoption of new technologies; cloud is no exception. These women took a chance on a new technology as much as they took a chance on themselves. With this new award, we want to honor that courage and bravery.

Cloud Girls Rising puts the spotlight on the most talented women in the space, who are advancing and shaping the cloud conversation. The yardstick for measurement is: innovation, solution orientation and thought leadership.

Professional accomplishment was weighted heavily in our consideration along with leadership skills and dedication to specific cloud technologies. We also thought it important to measure their involvement in mentoring other women in technology.

For Cloud Girls, giving back is a big deal.

The Cloud Girls Board of Directors—with assistance from the leadership of a like-minded sister organization called Women in the Channel (WiC)— developed criteria along with a scoring matrix for evaluating candidates for the award. These criteria include:

  • Achieving personal success
  • Evangelizing knowledge and change in the cloud space
  • Advancing the cloud conversation among women—from the classroom to the boardroom

We partnered with Channel Partners, a leading publication for the channel, to solicit applications from Dec. 1, 2015, through Jan. 15, 2016. A judging panel from Cloud Girls and WiC rated each applicant across the three categories.

We were impressed by the caliber of the candidates, making winner selection a challenge. Complicating the decision was the fact that the women were at various stages of their careers—mature leaders and up-and-comers.

Cloud Girls Trailblazer & Cloud Girls Rising Star

So, we chose to present two awards: Cloud Girls Trailblazer and Cloud Girls Rising Star. With these two awards, we can recognize those women who have laid the groundwork as cloud evangelists and those women who are showing incredible initiative and potential to be the next female cloud leaders.

We are excited to present these inaugural awards to two very deserving women on March 17 at the Channel Partners Conference & Expo in Las Vegas.

After going through this process, it is clearer than ever that there are many talented women in tech. So, we would encourage other groups to think about how they might recognize outstanding women in their space.

We want to encourage them to stay and contribute to the advancement of their fields. It’s important to let them know that their ideas, efforts, and hard work matter. They are valued.

Read more inspiring stories about women making a difference in the tech world and beyond at ItWasNeverADress.com and while you’re there, upload your own story! You could end up being a source of inspiration!

Jo Peterson, author of this piece, would like to thank Manon Buettner, an accomplished infrastructure architect, data center and cloud analyst and practitioner who helped write this article. She is founding co-chair of Cloud Girls.

Categories: Companies

Time To Abandon Agile?

NetObjectives - Tue, 03/15/2016 - 14:56
It depends on what you mean by Agile.  Net Objectives has been promoting Agile methods for the 17+ years of its existence.  Although we started by focusing on effective software development using design patterns and object-orientation, it was less than a year that we realized that developing code is not our real problem.  eXtreme Programming, Scrum and the Agile manifesto expanded our view to...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Shiny Objects and SAFe

The Agile Management Blog - VersionOne - Tue, 03/15/2016 - 14:30

shiny-objects-and-safe-800x328

R300x250-View-Nowecently, while I was teaching new teams on how Scrum fits in a larger Scaled Agile Framework® (SAFe®) structure, the question kept coming up from a product owner. “Yes, all this new Scrum stuff is great, BUT how do I juggle multiple requests from multiple stakeholders?” “My customers keep asking for more and more without taking anything off the plate.” I often refer to this as stakeholders chasing “the next shiny object.” Or, I want it all and I want it now.

Our business customers often fall into this mode due to the delivery nature of the waterfall projects we have been running for 40 years, where we deliver late, we do not deliver all they want, and it is not the best quality. As a result, I think they ask for everything they think they might need, which results in some of the difficulties of delivering what they REALLY need.

So the answer led me to explain how not only the Scrum teams deliver work, but how each of the teams is part of a larger ecosystem of project, program, and portfolio control that helps define work and priorities from original stakeholder requests to the work dispatched to the individual team members.

Walking the team through the SAFe Big Picture was exciting, and I’m not sure everyone took it all in a short time, but the questions kept coming: “Where do we fit in?” “What happens if I get buttonholed in the hallway and asked to do something by one of my customers, do I promise to deliver what they want?” and (well, you get the idea), new practices, new ways of acting and reacting to old situations. As team members they were afraid to tell a customer “No, we cannot do that”, or “I don’t know we have the staff to cover that request.”

In a recent engagement, the CIO never refused a request. We needed a way to corral her “Can’t say no” responses with SAFe. And we did. I’ll explain further a little later. The end result of these problems is a book of work that continues to expand, priorities that are not met, pet projects that take precedence and generally, queued work that gets out of balance with priority requests.

SAFe has some of the answers. We need to look at adding a strong helping of simple discipline and rigor following the SAFe principles and practices. But in my opinion, SAFe adoption alone is not enough – you need the Circle of Life in an IT shop: People, Practices, and Tools. All three combined are a recipe for success.

SAFe 4.0 Big Picture used with permission from © 2011-2016 Scaled Agile, Inc. All rights reserved. Original Big Picture graphic found at scaledagileframework.com.

SAFe 4.0 Big Picture used with permission from © 2011-2016 Scaled Agile, Inc.
All rights reserved. Original Big Picture graphic found at scaledagileframework.com.

People – SAFe does give us governance structures, roles that staff needs to play, and definitions of how they interact. This is highly valuable as it gives substance to the various roles in SAFe, while being flexible enough to add or revise, as needed. After all, it is a framework.

Process – With the introduction of Scrum and Product Owners, all the Inspect and Adapt cycles, potential added capabilities with Portfolio management to direct traffic, the picture looks a lot better from the standpoint of someone driving and managing those priorities. Now we actually have a framework to customize and make “our own” to manage a book of work for a medium to large shop (say 500 – 10,000 staff). New versions of “Essential SAFe” are available for smaller shops as well.

Tools – They give us the necessary discipline and rigor to carry through with the often complex dance of delivering systems and features to production. We need a single global collection point as a repository of the work to be delivered, a means of dispatching the work to various teams, a collection of metrics to report our current state, past efforts, future capabilities, compliance with practices, and so on. Tools provide us with the ability to do this. Strengthening the back-end delivery through DevOps is also a great capability to deliver.

Still, Stakeholders of Systems Want LOTS of Features

So, our business customers are still going to come at us from many different directions with a ton of Features, which can often be identified as “the next shiny object.”

What work may already be in stream or in construction can get impacted as the “next shiny object” can now be added to the list.

Shiny objects occur with amazing regularity as a result of:

  • A competitor introduces a new function – keeping up with the Joneses.
  • A stakeholder gets impatient for the delivery of a feature and becomes focused on that current shiny object.
  • A simple request in an email, which you mistakenly agree to do, goes from being a small paper airplane to a B-2 stealth bomber-sized project or program.

The results of stakeholders repeatedly chasing shiny objects tends to distract teams from delivery. Stakeholders can change their minds about what is important based on what is happening in the business world – which is often disconnected from our IT delivery world.

Unless we have a strong commitment to the SAFe processes and practices, we are unlikely to actually combat the shiny object syndrome.

SAFe practices corral, organize, prioritize, and deliver whole categories of shiny objects based on the needs and priorities of the stakeholders. At the portfolio level:

  • We corral, organize and prioritize (and even set the value of) shiny objects.
  • We use Kanban capabilities to organize and prioritize objects.
  • We use Value Streams to align work and fund the work (unfunded work like those B-2 stealth projects die at this point).
  • We make strategic level decisions for the good of the enterprise.

Remember that errant CIO who promised everyone who asked whatever they asked for? We gave her a sheet that became an input form to the portfolio screening process.

So what happens when that commitment starts to backslide or fail? How can we make sure a complex system of systems like this keeps on working?

SAFe is based upon a set of key Lean and Agile principles:

List of 9

Also of critical importance are the core values of SAFe:

ImageFor organizations to effectively implement SAFe, we also need a significant amount of individual and team based capabilities of rigor and discipline. In addition, we need some mechanism to keep us on track, and monitor speed, delivery, quality, and compliance, plus deliveries in a priority cadence that is driven by the stakeholders. Rigor and discipline of this type can come in the form of using an enterprise agile lifecycle platform (such as VersionOne) as a key to providing:

  1. Planning capabilities at various levels for various roles
  2. Metrics gathering and reporting
  3. Quick methods of prioritizing
  4. Globally distributed capabilities of defining and managing work

In my own experience working with large and globally distributed organizations, performing SAFe planning and execution, and utilizing technology with enterprise-wide capabilities of the caliber of VersionOne, provides them with the rigor and discipline to successfully be SAFe.

You can contact Tom Weinberger at www.linkedin.com/in/tomweinberger

Graphics reproduced with permission from © 2011-2016 Scaled Agile, Inc.  All rights reserved.

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

The post Shiny Objects and SAFe appeared first on The Agile Management Blog.

Categories: Companies

Agile @ Lego – our slides from Passion for Projects

Henrik Kniberg's blog - Tue, 03/15/2016 - 10:07

Here are the slides for our talk Agile @ Lego at Passion for Projects in Uppsala. Enjoyed discussing this stuff with project managers and the like from all sorts of industries. A common theme from the conference was the power of self-organization, and the role of leadership in creating the right context for self-organization to happen. Our talk provided a real-life large scale example of this.

2016-03-15 Agile @ Lego Henrik Kniberg Eik Thyrsted Brandsgård

Sample slides:

Agile @ Lego - KPI

Agile @ Lego - portfolio program team

Agile @ Lego - management review

Agile @ Lego - pulling from program backlog

 

Categories: Blogs

AgileEurope Conference, Gdansk, Poland, May 30 – June 2 2016

Scrum Expert - Mon, 03/14/2016 - 18:03
AgileEurope is a three-day conference organized by the Agile Alliance. With more that 20 presentations and 15 workshops delivered by Agile thought leaders, this conference will provide European agilists a place to learn and network similar to the annual Agile conference organized in the USA. In the agenda of the AgileEurope Conference, you can find topics like “Courageously, Compassionately, Confidently Learning: The Path to Agility”, “7 Sins of Scrum and other Agile Anti-Patterns”, “Agile Leadership and Self-organization”, “#DiscoveryDojo: Hunting Value with Structured Conversations”, “To Estimate or #NoEstimates, That is the Question”, “Experiences from Lean-Agile Hardware Development”, “One-Size Never Fits All: Tailor Your Agile Transformation to Meet Your Needs”, “How Architects nurture Technical Excellence”, “Agile Product Ownership – StoryMapping”. Web site: https://www.agilealliance.org/agileeurope2016/ Location for the AgileEurope conference: Gdańsk, Poland
Categories: Communities

A/B Testing Is Fooling You

Since Lean Startup became a fashion thinking for hipster entrepreneurs a Validation Run installed itself in our habits. Through (more or less...) Big Data Gathering we scan users behaviour on our site... Ok , I'm too judgmental here am I not? But hey, wait a little, awesome dreamers of successful startups, do you remember that "step-out-of-your-comfort-zone"- oh, sorry "out-of-the-building" I ment - attitude? How many times did you get out of the building to talk to real people ? How many times did you say "Nay, my users are not outside of my office door, they are ... elsewhere. How much do you prefer to stay a little bit hidden behind data collected on your website to make an educated guess about what that data might tell you about your customers ? How may times you longed for a good "how-to" on implementing A/B testing. But you know what ? A/B testing is narrowing your options. Here is why I think it does so.I wonder whether or not ...When was the last time you had this type of dilemma : "I wonder wether or not" .. do a specific action. Then eventually agonise on the decision. Then build Pros and Cons lists. Then throw them away ( or loose them...) , because we're not quite happy with what that list is telling us. To be more specific, let me give here a set of examples , hopefully you will recognise yourself in one of them at least :I wonder whether or not I should take that hobI wonder whether or not we should let go this member of our teamI wonder whether or not I should buy a new smartphoneI wonder wether or not I should go into that mountain hiking ....
The "whether or not" situation is not a real decision making situation, because we position ourselves in a one-dimensional Two-ways  option type. Having only one option is not an option. Having one option and its opposite it is not either. 
The "whether or not" situation was coined beautifully by Dan and Cheap Heath , who say that "whether you are asking yourself "whether or not" step back". You don't have enough of the big picture. In this case focusing to much creates blind spots of other options we might have at hand.
"I wonder if whether A or B" An "advanced" form of "I wonder if whether or not" is the "I wonder if A or B". Now, this might seem different to you, but it is not really. You are still in a kind of one dimension decision making process, because not doing A means implicitly doing B. Choices are narrow and you're stuck in your options.So let's see some examples here :
  1. I wonder whether I should buy a more expensive smartphone or stick to a basic one
  2. I wonder whether I should accept the offer from Harvard or Stanford 
  3. I wonder whether I should pick the blue shirt or the white one
  4. I wonder if web users will like a green call to action button or a red one?
  5. I wonder if I should write a new blog post or prepare dinner , 
  6. I wonder if my customers want a call-back button or a chat space.... 

I hope that I recognised at least one of the situation you eventually were in. And I hope for you that the majority of you were scanning for the answer to question number 2 :) The business experimentation movement accelerated by LeanStartup has came up with  receipt to answer questions like #4 and #6 in my example : The A/B testing! Yey, shiny! A/B testing says that we will implement non A or B , but A and B and then we wait and see. 
The Answer To A Question That Was Not Asked So here is the moment of gathering the data after the A/B testing. To all that implemented A/B testing I ask a question:What did you ( really) learn?The feed-back I have after each A/B testing starts with "hmmm...". Then it can go like this :"It seems A has more hits than B. But B is used heavily from 8:00 to 9:00 am. We should understand why"  or/and"It seems that A has more hits , but hey , isn't it because it's right in the middle of the page. B has very few hits but it gets traction each time."So, the global conclusion is we have collected very interesting data, just we don't have a clue what to do with it. In the "Whether A or B" situation we are still in a narrow focus situation , where we only think of A or B as options. In the specific case of A/B testing tool, the results are confusing because they just feed a behaviour data that blows at our face because they are not in our narrow scope of focus. That data simply answers to questions that we didn't fully ask.  It's like having a lot of indices , but no clue how to solve an enigma.  The gathered data is just like the messages intercepted by the British secret services:  encrypted by the Enigma machine during WWII they sound like gibberish.Once again , stepping back to have a bigger picture is necessary.
Enigma Encrypting Machine

The Vanishing Options Test 
What if instead of picking from that 1-dimensional-2-ways options ( Yes/No, A/B) we just force our brain to unfocused a little bit to get a bigger picture? Because, one field where focusing doesn't help is exploring (or identifying) real options. My favorite tool to" unfocus" to unfold creativity ( ie new options) is the Vanishing Option test , also defined as such by Dan and Cheap Heath. 

The test goes like this :
Imagine that all the options you have thought about are gone. E.g. you're stuck with an Yes choice, there can be no A and nor B, or there is only A.... Now think at the following question :What would you do in this situation to reach your goal?
Let's take an example : imagine you're sucked with a "light green colour/white text"  call-to-action button on your page. Can't change that! How would you improve your hits?  
Leave The Data Basement 
Collecting data is good, but remember, data is encrypted.  Just like having the Enigma Machine, didn't help allies to understand the messages, having a (BIG) data is simply not enough.  We need a decryption key, don't we? The bad news is this : the only decryption keys available for us are our own cognitive biases. So we turn gibberish to very probably distorted messages.
Nevertheless, there's good news , and it's called hope. As in many situations ( just like in Enigme decryption story, by the way), better answers come from changing perspective. There is one simple way to change perspective  for data interpretation:
Leave the deep basement behind your complex data graphs screen and go observe real users in the light. Talk to them. Ask them why A ? What does B mean to them?

Enjoy the sun!
Related posts 
Test Driven Business Featuring Lean StartupLean Startup Entrepreneurship Is Like Playing Video Games








Categories: Blogs

Empower Hour: Use Your Voice to Engender Change

About SCRUM - Hamid Shojaee Axosoft - Thu, 03/10/2016 - 17:37

If you weren’t on any type of social media on Tuesday, March 8th, there are two things I have to say to you: 1. “Wow, great job unplugging” and 2. “It was International Women’s Day! Everyone was using the hashtag #IWD2016. Twitter even inserted a tiny female gender symbol at the end of every hashtag. It was adorable.”

But in all seriousness, how did YOU celebrate? Did you take a moment to think about the strong, cool women in your life and how they probably will have to wait another 118 years or so to earn as much money as a man in the workplace?

Or maybe you thought about the women in 1857 who worked in the garment industry in New York City and decided one day to walk out of their jobs, picket and demand improved working conditions—you know, simple things like a 10-hour work day and equal rights. Or maybe you decided not to think, but to take action!

One Audacious Act

webinar
We decided to take an hour to invite all people, across the world, to participate in a free webinar and creative writing workshop led by Axosoft’s literary ladies, Trista Sobeck and Tania Katan. No one rioted, no one picketed; in fact, it was quite calm.

However there was one audacious act being committed: the instruction of how to use your voice and do some writing. This is actually pretty powerful. Just ask Audre Lorde, Gloria Steinem, Angela Davis, Laverne Cox and Harriet Beecher Stowe.

So, in case you missed the webinar, “Empower Hour: Use Your Voice to Engender Change,” don’t feel too terrible. You can still watch the recording. Also, you can read about 5 things that can make you a better writer, thinker and communicator. After all, these are the tools that can really help you change the state of women’s rights.

1. Pick up your room. It’s too cluttered.

The novelist/philosopher/playwright/screenwriter, Ayn Rand, said,

“Words are a lens to focus one’s mind.”

I take this to mean, “Look, your living room has 1,000 random things hanging around and you are going to trip on something on your way to the bathroom.”

Writing can really help you clear up that clutter that is preventing you from taking any kind of action, whether it’s speaking up for yourself in that meeting you had earlier in the day to telling a car salesman that you really aren’t interested in the color of the car, but rather the miles per gallon it gets and the horsepower.

The bottom line here is that clarity is power. How can you get it? Write 5 sentences a day about anything. You may feel a little less foggy.

2. Get over yourself; writing isn’t about you.

Writing is about communicating. You’re trying to tell somebody (your boss, 100 tech executives, 15-year-olds who are enamored by vampires, etc.) something. So, shift your thinking and step outside of your head. It’s a little scary, yes. But outside of your head is where the real action takes place.If this freaks you out, take a cue from Audre Lorde, writer/feminist/civil rights activist,

If this freaks you out, take a cue from Audre Lorde, writer/feminist/civil rights activist,

“When I dare to be powerful, to use my strength in the service of my vision, then it becomes less and less important whether I am afraid.”

So, think about what is important to you. Is it parenting? Is it helping those who need a hand? Is it education? If you can use your words to make a difference in the things you are most passionate about, why wouldn’t you use your words and write?

Make your passion bigger than your fear; it’s entirely possible you could make a difference in the world.

3. Your voice is just the sound you hear in your head.

You’ve heard the statement, “you have to find your voice.” Well, guess what? You really don’t have to find it. You already have it! No one said you should write like Joan Didion or Shakespeare. You are you, so you probably won’t write like those folks.

Get comfortable with how you sound, the things you say, your own unique quirks and “isms.” The more comfortable you are with how you sound, the more you’ll embrace it.

In order to do this, check out this quick exercise that you can do in only 5 minutes.

Exercises in Finding Voice: Author Tania Katan
  • Make a list of your verbal “quirks;” anything that is specific to you and how you speak. For example, do you say, “whatevs” or “totes” or “btw” or do you make up your own words? Capture those and write ‘em down.
  • Write 2-3 sentences using those “isms.” Describe something just the way you would to a friend using your unique rhythm and tone.
  • Do this a couple times a day. You’ll get to recognize your voice in a crowded airport. And you’ll hug it like it’s returning from a long trip.
4. Your thinking can derail everything.

Thinking is a good thing to do. For example, should you yell back at your boss after they ask you to rework a project you’ve worked on for weeks? Nope. You should think about it, recall all the consequences associated with yelling and then proceed calmly. Redo that project regardless of your feelings.

When it comes to writing, what you need to do is turn off your thinking.

Take a pen, put it to a piece of paper and write—about anything. If you need a prompt or some ideas, go to where all of us go to get ideas these days: Google. Look up: “writing prompts,” you’ll find at least a billion.

You could always call your best friend, partner, spouse, ex-boyfriend and say, “Hey, i’m going to write. Give me something.” They will. Even the ex.

Now, open up your journal and write for 5 minutes about that. Do not stop. Do not judge yourself or your words. Most of all, don’t think.

5.  It’s always going to be a practice. Get used to it.

If you’ve attempted to run a 5K or a 10K or any type of marathon, you know you have to practice. You don’t just show up and run 26.2 miles. You have to practice and train. You get out there every day and put one foot in front of the other. You do this because you know that on the day of the race, your body will know what to do.

Muscle memory is awesome like that. It’s the exact same when it comes to writing. You’ll sit down, with a journal or your blank computer screen and just start. And one day, you may find yourself with a chapter or a complete book.

The best thing about these tips is that you can start using them today and share your work on itwasneveradress.com. Go ahead, even though International Women’s Day is over, it doesn’t mean progress halts! I hope you take some time to celebrate yourself (and all humans) every day of the year.

And we have another event just around the corner to celebrate strong, amazing women. Please join us April 17-19 in Downtown Phoenix, Arizona for Catalyst Conference in partnership with the global non-profit Girls in Tech.

GirlsInTech2016
The Catalyst Conference will provide attendees with an environment for true and honest conversations about important issues including gender diversity in the workplace and how we can better support women in tech. There are more than two dozen notable female speakers confirmed for this year’s event. Get early bird ticket pricing by registering now!

Categories: Companies

Building Complex Systems with SAFe

The Agile Management Blog - VersionOne - Thu, 03/10/2016 - 15:30

building-complex-systems-with-safe-800x328

By Alex Yakyma and Harry Koehnemann

300x250-View-NowVersion 4.0 of the Scaled Agile Framework® SAFe® was released just about two months ago but has already generated keen interest on behalf of complex systems builders and large software enterprises. The new version provides specific depth for organizations that build world’s largest and most critical solutions. Version 4.0 has a new optional layer that includes a set of practices for building large, complex systems in a Lean and Agile manner. It provides better modularity and addresses a number of challenges that large systems builders encounter when organizing around the flow of value, such as coordinating Agile Release Trains in a large Value Stream, or coordinating multiple value streams in the portfolio.SAFe-Value-StreamIn this article we will discuss the challenges large systems builders face and key approaches for addressing them. But before we start down that path, let’s understand first what makes complex systems development so complex.

The Roots of Complexity

So, what makes the development process so much harder in the world of large, complex systems? Let’s consider some common factors:

  1. The multidisciplinary nature of the systems. These systems require collaboration and integrated components from a broad set of deep engineering skills that include software, firmware, hardware, electrical, mechanics, optics, and hydraulics, to name just a few.
  2. The architectural complexity of the systems. Even in the case of pure software, complex solutions may contain hundreds, or even thousands, of interconnected components, subsystems, services, and applications.
  3. Legacy technologies. Modern systems leverage existing solutions initially developed (potentially) decades ago and involve high cost of change and poor support for modern ways of engineering and testing.
  4. Complex production environments. Our complex operational environments challenge the creation of equivalent environments for integration, testing, and demonstration of results.

These factors are sometimes mistakenly considered impediments to adopting Agile and Lean. However, let’s explore where we stand with traditional methodologies.

Traditional Methods Are Not Up to the Task

Traditional, phase-gate methods fail to cope with these complexities. Despite heavy weight and robustness, they are subject to a fundamental flaw: the assumption that complex systems can be “figured” in a speculative, detailed, up-front manner. As a result, enterprises prematurely commit to detailed requirements and design before any actual learning begins, therefore dismissing a broader variety of more economically beneficial solutions that may emerge later. They fail to ensure quality and fit for purpose because of heavily inhibited feedback. They run over schedule and budget due to lack of objective measures of progress, measures that would rely on tangible increments of the solution rather than the amount of effort already spent or other poor proxies for value.

Despite all the problems with traditional methods, transition to Lean and Agile is often impeded by a number of myths that surround complex systems development. Let’s consider the most common ones:

Myth 1: Frequent integration and testing is not possible in the case of hardware development (or other non-software domains).

Myth 2: People from different domains (SW, FW, HW, etc.) can’t work together.

Myth 3: Complex systems development must follow the phase-gate process model to be successful.

 Myth 4: Non-software disciplines cannot produce meaningful value in small increments.

Let’s try to take a more pragmatic view and address these myths referring to a more generic view across all engineering disciplines as part of product development.

The Problems May Be Different But the Principles Are Universal

In his article on Agile in hardware development, Ken Rubin concludes that applicability of Agile methods is not a binary choice but rather is influenced by the cost of change of the underlying system. Hardware, he argues, has a higher cost of change than software. This dictates certain adjustments but does not exclude agility—just the opposite, in fact, since the cost of error is also often higher in the case of hardware. Dantar P. Oosterwal, in his book The Lean Machine, shares the experience of Harley-Davidson in their search of a better product development method. The great epiphany, he points out, was to realize that the success of a new development initiative did not depend on the success of individual phases in the process. Instead, projects that went through multiple, consequent design cycles supported by actual system integration were significantly more successful than their “waterfalled” counterparts.

These and other examples suggest that complex systems development is governed by a leaner and more Agile set of principles. Furthermore, these principles would hold true for different business contexts, engineering disciplines, and solutions. SAFe considers nine such principles:Principles

Having stated a set of governing principles, now is the time to consider specific practices and patterns for complex systems development.

Putting the Principles to Work

We will split the discussion of implementing the practices into three sections:

1 – Organizing Around Value

Large, physical systems often organize around functional areas. Organizing around function or discipline helps ensure technical integrity, but it also contributes to handoffs, delays, and waiting across team boundaries. SAFe adopts a more pragmatic approach: organizing around value. This paradigm aims at the key goal of establishing the shortest sustainable lead time in value delivery, and it achieves it by building organizational units in such a way as to contain most dependencies inside each unit rather than spreading them across different units.Dependencies

Building fully cross-functional and cross-domain Agile Teams (of 6 – 9 people) may not be feasible in many cases. However, creating an Agile Release Train—a self-organized team of teams that usually consists of 50 – 125 people—that includes all functions and aspects of engineering is absolutely feasible in most cases and should be done whenever it meets the objective of establishing a sustainable, fast flow of value.ARTsLet’s consider an example: a product that involves software, firmware, and hardware development, with hundreds of engineers in all domains. How should we organize the trains?

For that we need more context. Let’s say that in our particular case, hardware is tightly coupled with firmware, which in turn creates an abstraction layer for the software operating system and the specific applications and services that run on top of it. This gives us the first cue: putting hardware and firmware engineers on one Agile Release Train is probably a good idea. And in case we end up with too many people, we might end up with multiple FW-HW trains, each organized around a subset of the key system capabilities. But should software teams be on these same trains as well, or should they be separate?

In the case of our system, hardware and firmware changes are being released at a relatively infrequent rate, while software teams should be able to produce over-the-air updates every few weeks. Given both decoupled interfaces and release schedules in this particular case, we might benefit from actually having software teams on a separate train.Example2 – Synchronize Development

Once organized in the structure that supports value creation, we need to establish the actual rhythm of development. Aligning on a common cadence creates such a rhythm by focusing large programs to the work in the current Program Increment or PI (8 – 12 weeks), reducing excess work-in-process (WIP), and making unpredictable events more predictable. This common cadence aligns the diverse value stream members we find in these large, complex systems. We expect practitioners from different engineering domains, as well as Suppliers and the Customer, to participate in the PI Planning so they can understand what we are building as a set of ARTs in a larger value stream. SAFe® 4.0 provides additional mechanisms of alignment via Pre- and Post-PI Planning, in addition to the standard PI planning routine practiced by Agile Release Trains.

Teams on the train also execute on a cadence of short Iterations, each providing a demo of an integrated increment within the ART’s area of concern.

To close the loop, PI boundaries provide Inspect and Adapt opportunities that build on the objective measure of progress—the integrated, end-to-end Solution Demo. Thus the cadence provides the “meter” for incremental Solution development from end to end—the direct opposite of the phase-gate process model.SolutionIn order to support such a cadence, teams and trains in the value stream need to learn to frequently integrate and test.

3 – Frequent Integration and Testing

Delivering value quickly challenges large systems due to the lead time needed to acquire and then integrate their functional parts. Despite those challenges, we strive to demonstrate value quickly by continually providing increasingly closer approximations of the end-to-end, integrated solution. We create these closer approximations at least every PI, and possibly every iteration, to demonstrate progress and provide objective evaluation of the current solution for stakeholder feedback.

Achieving these frequent learning Milestones may be difficult when aiming only at a full, end-to-end integration of all subsystems and components. We might need to look for a way to provide approximations for the subsystems of the real solution for which the cost of integration will be sufficiently low and that would allow us to perform such integration on a frequent basis. When we do so, and replace a subsystem with a simpler “proxy,” we reduce the cost of integration but may negatively impact the quality of feedback from such integration. So, for example, replacing the subsystem with a primitive stub may incur significant cost later, when we learn that we made a number of false assumptions based on a very shallow proxy for our subsystem. In the general case, we are dealing with an economic trade-off, as the picture below suggests.

Cost

The horizontal axis represents different possible ways to “proxy” the subsystem behavior. It starts with the subsystem itself (as an ideal, perfectly accurate proxy) and follows a range of cyber-physical proxies through to pure software alternatives and all the way to the simplest possible stub. The vertical axis represents the cost associated with the process. The blue line shows decreasing cost of integration, while the grey line represents increasing cost of inaccurate feedback as we move from more complex and accurate approximations to more lightweight and primitive ones. Somewhere in the intersection of the two curves lies the optimum choice for our subsystem.

If we look at the entire solution, such a decision generally needs to be made for every subsystem.Entire solutionEach subsystem has its unique correlation of cost of integration and feedback fidelity. Therefore, we require a balanced approach to identifying the best point on the spectrum of possible proxies. The entire solution integration then relies on the respective choices for each subsystem: for example, some may be high-fidelity proxies, some may be actual subsystems and some may be just stubs, as the picture above suggests.

It is also useful to consider a more “incremental” approach to picking the right spot on the spectrum for different subsystems. It is not uncommon for hardware engineers to separate logical control from their physical device to create a closed testing loop. Initially, when no functional behavior exists, stubs that simulate the subsystem’s request-response behavior serve as proxies for integration and testing. Also, early in the process teams may use models (model in the loop, or MIL) that later evolve to software (SIL) and eventually hardware (HIL) proxies. Each step more closely approximates the sweet spot.

Summary

In this article we considered the key challenges that make complex systems development so complex. While some may appear to be impediments to the adoption of Lean and Agile practices at the first glance, it is even more critical to apply Lean and Agile where cost of error may be incredibly high. We explored the myths that surround Lean-Agile in a complex, multidisciplinary world and tried to take a balanced view based on SAFe principles—immutable, universally applicable “laws of physics” that govern product development. We put those principles to work by considering specific implementation of the core practices around organizational structure, synchronized development, and integration and testing. We showed how practices could be adjusted to provide improved results in different contexts based on selective optimization.

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

The post Building Complex Systems with SAFe appeared first on The Agile Management Blog.

Categories: Companies

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.