Skip to content

Feed aggregator

3 Reasons to Be Excited About Agile This Fall!


The trees changing color is usually top of the list of reasons to love fall, while crummy weather is right there are the bottom. Luckily we have three more reasons for you to love this fall (and to get out of bed when the rain and clouds sap your motivation)!

  1. SAFe Partner Summit (Denver, CO)
  2. Southern Fried Agile (Charlotte, NC)
  3. Lean Startup Week 2016 Livestream (Chicago, IL)

That means more of your favorite Agile Amped podcasts!

SAFe Summit 2016

We’re excited our partnership with Scaled Agile has continued to grow and this year we will be capturing all the action at the SAFe Summit conference! This conference aims to provide a place where SAFe practitioners, coaches and thought leaders can share their knowledge and thus create a richer experience for the entire industry. Agile Amped will sit down with many of the speakers and event panelist, so if you’ve got SAFe on the brain, don’t forget to subscribe (below)! Follow the action with #SAFeSummit and @ScaledAgile!

Southern Fried Agile

What’s not to love about an Agile conference that spends the day helping Agilists connect and share knowledge fried chicken? Agile Amped will be on site at Southern Fried Agile, speaking to the industry’s leading thinkers including several of our own consultants. Here’s what you can expect from our speakers:

The list of speakers features many new voices as well as some crowd-pleasers that have already graced the Agile Amped podcast, including Christopher Avery, Kent Graziano and keynote Esther Derby. Don’t forget to check out @sthnfriedagile to see what’s happening before, during and after the event!

Lean Startup Week 2016 Livestream

The first week of November is Lean Startup Week in San Francisco, and this year SolutionsIQ is partnering with Lean Startup Week and WeWork to bring a livestream experience to Chicago! Attendees will be able to watch the full livestream from the conference, ask SolutionsIQ consultants and coaches for advice on Lean Startup, enterprise innovation and Agile, and then tour the WeWork facilities. Lunch and beer is included with your free registration! But be quick about it: space is limited and it’s already filling up.

Learn More or Register

If that’s not enough reason, stay tuned for an invitation to our upcoming webinar on the mysterious “innovation colonies”!


The post 3 Reasons to Be Excited About Agile This Fall! appeared first on SolutionsIQ.

Categories: Companies

Leading to Real Agility – Leader Responsibilities

Learn more about transforming people, process and culture with the Real Agility Program

Leading an organization to Real Agility is a complex and difficult task.  However, the core responsibilities of leaders attempting this are simple to describe.  This video introduces the three core responsibilities of the senior leadership team as they lead their organization to Real Agility.

The video presents three core responsibilities:

  1. Communicating the vision for change
  2. Leading by example
  3. Changing the organization

Future videos in the series will elaborate on these three core responsibilities.

Real Agility References

Here are some additional references about how leaders can help their organizations move towards Real Agility:

Please subscribe to our YouTube channel to receive notifications when each new video is published! (There are 15 more videos coming in this series, and more beyond that on other topics!)  You can also find the summary article that helps you find all the videos and additional references here: Leading to Real Agility – Introduction.

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BESTEIG Real Agility logo


Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Leading to Real Agility – Leader Responsibilities appeared first on Agile Advice.

Categories: Blogs

Contoso University updated to ASP.NET Core

Jimmy Bogard - 13 hours 29 min ago

I pushed out a new repository, Contoso University Core, that updated my “how we do MVC” sample app to ASP.NET Core. It’s still on full .NET framework, but I also plan to push out a .NET Core version as well. In this, you can find usages of:

It uses all of the latest packages I’ve built out for the OSS I use, developed for ASP.NET Core applications. Here’s the Startup, for example:

public void ConfigureServices(IServiceCollection services)
    // Add framework services.
    services.AddMvc(opt =>
            opt.Conventions.Add(new FeatureConvention());
            opt.ModelBinderProviders.Insert(0, new EntityModelBinderProvider());
        .AddRazorOptions(options =>
            // {0} - Action Name
            // {1} - Controller Name
            // {2} - Area Name
            // {3} - Feature Name
            // Replace normal view location entirely
            options.ViewLocationExpanders.Add(new FeatureViewLocationExpander());
        .AddFluentValidation(cfg => { cfg.RegisterValidatorsFromAssemblyContaining<Startup>(); });

    services.AddScoped(_ => new SchoolContext(Configuration["Data:DefaultConnection:ConnectionString"]));
    services.AddHtmlTags(new TagConventions());

Still missing are unit/integration tests, that’s next. Enjoy!

Categories: Blogs

Targetprocess v.3.10.2: Redesigned Projects-Teams Selector, Batch Add Comment

TargetProcess - Edge of Chaos Blog - 14 hours 11 min ago
Redesigned Projects-Teams Selector

We expect this release to reduce the system's complexity quite a bit, as we have redesigned the projects-teams selector. Previously, your selection of projects and teams would be globally applied for all views that you opened. This caused some confusion, especially when users with different projects-teams selections collaborated on public views.

To remedy this, we've made the projects-teams selector a part of each view's settings. All users will now see views with a predefined projects-teams selection applied. This predefined selection is set by the view's owner.

You can still look at any view through any projects-teams context that you want by clicking on the selector. When you change the selection for a view, the selector will be highlighted yellow, like this:


This highlighting attracts your attention to the fact that you have changed the projects-teams selection for this view, and so you are looking at a different set of data than other users. There is a handy 'revert' option to quickly sync the view's projects and teams back to its public settings.

For more information, see our dedicated blogpost on this change, or check out the Projects-Teams Selector article in our User Guide.

Batch Add Comment

You will now be able to batch-add brief comments from the Batch Actions Panel to a group of selected items on a Board view.

batch add comment

Minor Features
  • Modified Date as lanes
  • Emojis in the Tags lane
  • Batch update of checkbox custom fields
  • Epics added to the Process Control chart, Cycle Time Distribution and Relations network diagram
Fixed Bugs
  • 'Open in new tab' doesn't work properly in Safari Version 10.0 for MacOS
  • Login page sometimes did not accept valid emails
Categories: Companies

Projects-Teams selector redesign

TargetProcess - Edge of Chaos Blog - 14 hours 18 min ago

Our upcoming release (v.3.10.2) will contain a complete redesign of the projects-teams selector. To reduce complexity, we've made the selector a part of views (rather than a global setting found on the top bar). It will now be clear if a view is displaying data from the default project-teams selection made by the owner of the view, or data from the projects and teams selected by you.

Old version:


New version:


We made these changes to solve two main issues. The first is that data in views would unexpectedly change because of unintended projects-teams selections. This happened when you navigated through views with and without predefined selections by the view owners. It was sometimes unclear why certain projects and teams were displayed in certain views.

The second issue would occur when users collaborated on views. It was often unclear for users that they were seeing different data than their teammates because they had set a different selection of projects and teams. To fix this, we've made the projects-teams selector as straightforward as we can. You will now always know what data you're looking at on the view and why.

By default, a view will show the selection set by the view owner in View Setup. 

You can still make a view display data from any projects and teams that you need to see. When you modify the set of projects and teams shown on the view, the selector will be highlighted.


These changes are applied only for you; other users will still see the view with the predefined projects and teams selected by the view's owner. 

Once you set projects and teams for a view, your selection will be saved for that view. You can easily revert back to the predefined selection by clicking the revert button.


If the view's owner hasn't set a projects-teams selection for the view, then the revert action will not work because there is nothing to revert to.

For more information, visit the Project and Teams Selector article in our User Guide.

Categories: Companies

Being An Agile Security Officer

Xebia Blog - 16 hours 31 min ago
Whenever I give a presentation, training, or just talk to security teams, it becomes clear that over the years a gap has been created between application security and development. A gap we created consciously and with intent and that became painfully visible with the introduction of Agile and DevOps. Suddenly exhaustive information security policies with
Categories: Companies

Working Remotely in an Agile Team

TV Agile - 20 hours 42 min ago
This is story of how adopting Agile practices helped Olly Brand work remotely from Cornwall as part of a global team at IBM. Lessons learned on the journey adopting Agile. How to use Agile methods to deliver across different time zones, working in a global market place. In a world that requires us to be […]
Categories: Blogs

The Geek Guide to Leading Teams

Scrum Expert - 20 hours 47 min ago
This presentation uncovers a number of key principles and useful tools to help you better skills as a geek who leads Agile and Scrum teams. The most challenging aspects to software development are always the people issues. Picking the right data structures, finding the right testing approaches are simple compared to building an effective software team. Most organisations fail to support developer promoted into technical leadership roles so where do you go to uncover the secret skills behind this important role. Watch this video to discover practical tips for leading technical teams. Video producer: In this talk, we will
Categories: Communities

Technical Debt Is A Systemic Problem, Not A Personal Failing

NetObjectives - 21 hours 39 min ago
One of the underlying themes of the work we do at Net Objectives is, Agile by itself is not enough. Agile needs something that connects the transformation of the team to the activities and concerns of the larger organization. Nowhere is that more clear than technical debt. You need to nestle Agile within a larger operational approach, such as Lean, to deal effectively with a problem like...

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

The Strategic Planning Cycle

Agile Elements - Fri, 10/21/2016 - 06:07

Some think of strategic planning as a one time or every 3 years exercise. In my experience, it is most beneficial to think about it as a yearly cycle.

This time of year is when many organizations refresh strategic objectives and tune longer term plans. Finishing strategic planning efforts by October allows for those deliverables to feed into the annual planning cycle and prevents conflict between the two efforts. I like to think of strategic planning as an on-going process that is evaluated and refined every quarter, but also has a specific focus each quarter. A typical cycle is:

Q1 – Detail Department Plans (focus on Product Road-map and Sales Enablement)

Q2 – Talent Management (MBO’s, Talent evaluations, Comp review, Key resource needs)

Q3 – Strategic Planning (3-5 yr SWOT, Themes, Objectives, Metrics, Goals, Initiatives)

Q4 – Annual Operations Budget and Staffing

Using a strategic planning cycle ensures the strategy stays relevant and gets translated into execution more effectively.


Categories: Blogs

Focus – my keynote at AgileByExample, Warsaw

Henrik Kniberg's blog - Thu, 10/20/2016 - 09:52

Here is my slide (yes, it’s just one slide) from my keynote at AgileByExample in Warsaw.


And a couple of photos:

Flow demo

A live demo of flow vs resource utilization. Assisted by my two youngest kids

Categories: Blogs

Essential SAFe at Milwaukee Scaled Agile Meetup

Agile Product Owner - Wed, 10/19/2016 - 20:19

Hi Folks,

We had an excellent session at last night’s Scaled Agile Meetup in Milwaukee. Thanks to my hosts at Northwest Mutual (Jill, Sarah and others) and Icon Technology (Stella) for putting on such a good show. We had about 300 people registered. I presented a new talk on Essential SAFe, a topic that is near and dear to our hearts (and yes, to some future update to SAFe 4.0).


You can download the presentation below. And special thanks to Inbar for creating this new deck!

Download Essential SAFe PPT 

Also, and FYI, I’ve created a new blog category for Essential SAFe, which should help tie together this important work in process.

Stay SAFe!

—Dean and Team

Categories: Blogs

Participant observation for IT managers

Kanbanery - Wed, 10/19/2016 - 19:47

Artykuł Participant observation for IT managers pochodzi z serwisu Kanbanery.

Most innovation is just stealing ideas from other fields. For example, peanuts used to be shelled by hand. Imagine a factory floor with hundreds of people doing nothing but shelling peanuts. Why would a person who works in the nut business know anything at all about canning vegetables? They wouldn’t. But one day (so the story goes) a fellow who owned a peanut business found himself visiting a bell pepper canning plant. He saw something amazing. Rather than core the bell peppers by hand, they had a big drum that they’d fill with peppers, seal, and pressurize. Bell peppers are slightly porous, so the pressure would rise inside the peppers to match the outside pressure. When they suddenly opened the drum, the pressure was released, and the bell peppers exploded, blowing out their cores. A pessimist sees a whole lot of peanut workers being out of a job soon. An optimist would invest in peanuts. I heard that story decades ago; so I might have gotten it backward.

I’ve worked in some very different industries, from prisons kitchens to marketing agencies and from event planning to competitive intelligence. So for me, sharing with the IT community something that everyone in another field already knows is the low-hanging fruit of blogging. But I never know when my observation will be someone else’s peanut epiphany, so why hold back? I did that two weeks ago when I shared something I learned from the world of TRIZ, and I’ll do it again today.

MalinowskiMalinowski in the field

I was trained as an anthropologist. The most well-known tool of anthropology is participant observation, which seems simple enough. After all, it was discovered by accident. A fellow who went to school just down the road from the Krakow office where I’m writing now, went off to do a short study of people living on islands near Australia. It was 1914 and he, an Austrian subject, left Europe for his first big adventure abroad. As it was, something else really important happened in 1914. As an Austrian, Malinowski found himself on the wrong side of the war and had to stick it out with the Trobriand Islanders for rather longer than he’d expected. Years longer than he’d expected. When he came back and published what has become one of the most important texts in the annals of ethnography, he was rather sold on the idea of spending a lot of time in close contact with the subjects of a study. (In all fairness, Frank Cushing did something similar first, but it’s Malinowski who gets remembered for “discovering” participant observation because Cushing liked it a little TOO much and didn’t get around to writing most of his experiences down).

Why does any of this matter? I ran into the idea again in business school when I heard about the lean manufacturing practice of walking the gemba. That’s Japanese for getting off your butt and visiting the shop floor from time to time. A few years later, mostly thanks to Mary and Tom Poppendieck and later David Anderson, tech workers got keen to learn Japanese, too. Walking the gemba proved to be one of those lean manufacturing concepts that didn’t quite translate directly to knowledge work. For many IT managers it meant just being accessible to the engineers, which is rarely a bad thing, but they couldn’t really see how the work was being done the way a factory manager could. If they tried, following the “management by walking around” fad, the result was what one of my employees was overheard to call “management by looking over my shoulder.” The CEO of one of my companies took it to an extreme with his “flying office” which works great if your goal is to blur the distinctions between manager and employee (it was, in his case). All of these things, walking the gemba, management by walking around, and flying desks, allude to learning through participation. So just maybe some of the theories and practices of a hundred years of participant observation by anthropologists and sociologists might have something to contribute.

The first major distinction between walking the gemba and participant observation is that the latter is a research method guided by theory. The anthropologist has an idea about how things work, and they’re applying that idea to gathering data. The theory defines what is worth looking at and asking about and what isn’t. It makes sense of the complexity by imposing some constraints. A theory might be “social institutions emerge to serve survival goals” and so the ethnographer would concentrate on understanding social systems and their impacts on the life of the group.

In the 90’s, when the whole idea of objectivity in anthropology was being questioned and eventually dispensed with, theory got a re-think. Glaser and Strauss developed an approach to emergent theory called grounded theory (that isn’t as opposed to “ungrounded theory” but rather refers to developing a theory that is grounded in data), which very simply put is an approach to making sense of disparate data by finding patterns in it, and discovering a theory that can explain those patterns. I write about how I use it to analyze textual data in a post on one of my blogs.

So the anthropologist begins participant observation with a theory or with an approach to producing a theory and some research problem or question. These help them to know what to look for. Will they spend their days counting vegetables in personal gardens or mapping family trees? That’s why we have books like “Coming of Age in Samoa” and not a 10,000-page tome called “Samoa A-Z”. Would a problem, a question, or a management theory help to make time spent in the gemba more productive? Perhaps.

Next, anthropologists collect data, not just feelings and impressions. Their data is a mix of observations, interviews, polls, surveys, stories and artifacts. They take careful notes in the field and spend their evenings expanding on those observations while memory still holds. They understand that their ideas will change and evolve and that those ideas will shape their memories and so capturing data as accurately and promptly as possible is key to maintaining some bit of objectivity and to offset the risk of recency bias (wherein impressions are skewed more by recent observations than by earlier observations).

There are two fundamental rules of fieldwork that all good and decent anthropologists who don’t want to get drummed out of their cushy teaching jobs adhere to: informed consent and protection of their subjects. Informed consent means that the people we’re trying to understand know who we are, what we’re doing, how we’re doing it, and why we’re doing it and they give us permission to be there. Protection of subjects means that we take measures to ensure that no one gets hurt by helping us. Usually, that means anonymizing any data that could identify an individual. If a manager moves his desk into the dev room with the intention of watching the employees so he can stack rank them based on their work habits in preparation for the next round of corporate layoffs, but tells them that he just wants to understand their environment better, then he’s violating both of those core ethical rules. He’s misrepresenting himself with the intention to do harm. Please don’t do that.

Guided by a research goal and theory and constrained by a code of ethics, anthropologists entering the field begin by explaining their work and gaining permission. The permission can come initially from an authority like a police chief or village elder, but ultimately everyone who is interviewed or has any prolonged or close contact with the anthropologist has to understand that they are being observed and why and should have a chance to bow out if they think it’s creepy.

How might a manager explain their new desk in the team room? “I want to understand how things work here so that we can create policies that address real issues and work within the constraints you work under.” Or “I want to learn from you how the work gets done so that the process models that we use can better reflect reality.”

The first days in the field are mostly about getting settled and fitting in. The anthropologist pays attention to how people behave in much the same way a new student at school might be hyper-sensitive to social patterns to figure out how and more importantly, where, to fit in. When a new person enters a group from the outside, with the expressed purpose of gathering data for some cause, there will be people in the group who see that as a threat and others who see it as an opportunity. The anthropologist will be approached by people with their own agendas as well as by people who are naturally gregarious or curious. She has to start thinking about who to trust, who can provide deep insights, who has connections that could help and who is just pretending to have connections.

A manager entering the field will encounter much the same. Job titles and organizational charts of are of limited use when trying to determine the real pecking order in the dev pit. A junior dev may be the go-to person security issues just because she’s really easy to talk to and good at guiding the conversation in unconventional directions. You won’t know things like that until you’ve sorted the sycophants from the naturally helpful in the group and found your own place in the team and then eventually become so boring in your naturalness that you can sit quietly and watch.

Once you do start noticing interesting patterns, like the frequent visits to that junior dev’s desk, you’ll need those well-informed and well-intentioned informants to bounce ideas off of to test whether your conclusions are correct.

Aiming for accuracy, observation alone is not enough. Anthropologists in the field collect data in various ways. The make careful observations while in the course of participating in a group, but they also conduct formal and informal interviews, use questionnaires and take polls, take pictures and video, and look for objective data like who goes to lunch together, who plays foosball together, and who goes to whom for help, who is consulted on different types of decisions, and how often. They try to get multiple types of data to confirm or reinforce their conclusions.

One of the great things about informed consent is that since the people you’re studying know why and how you’re doing it, you can ask them to validate or question your conclusions. Key informants are usually people ideally suited to test ideas on, because they’re well-informed and you’ve spent a lot of time building up a rapport with them.

By its nature, participant observation results in subjective conclusions. It’s a research method that is difficult to reproduce. Two anthropologists spending time with the same people will arrive at different conclusions, neither of which is necessarily “wrong.” Ethnography produces no definitive answers. It’s used in the social sciences to provide context for other, more objective, data. For example, your HR department may have highly objective numbers on staff attrition combined with somewhat more subjective but still highly constrained data from exit interviews. They may paint a picture of a problem in one department without providing enough data for a policy decision. Fire the manager? Raise salaries? Start a softball team? Lay off troublemakers? The wrong decision could make the problem far worse. A month of working in the department and getting to know the staff there as peers could fill in a lot of the unknowns and suddenly HR’s data has context; it makes sense.

Participant observation provides the big picture that Clifford Gertz called “thick description.” Gertz described the idea of “thick description” best and quite cleverly when he introduced it using the example of a wink. Anyone seeing a wink for the first time might objectively describe it as a person briefly closing only one eyelid and then opening it again. That’s an accurate description. But how well you’d have to know a group of people and understand the social situation to distinguish between a lewd wink, a friendly wink, a sly wink, and a person making fun of another person’s lewd wink. The story that makes sense of the wink is the level of description that the ethnographer is aiming for, and it’s the level of understanding a manager needs to formulate policies that won’t be met with a wink and a nod.

Artykuł Participant observation for IT managers pochodzi z serwisu Kanbanery.

Categories: Companies

5 Practices for an Agile Mindset

Agilitrix - Michael Sahota - Wed, 10/19/2016 - 18:17

Excited to share slides from my workshop/talk at PMI Professional Development Symposium in Toronto today. Great group. Great questions. A lot of motivated, caring people in the room today. Agile Mindset Summary “Agile is both a set of practices and a mindset. Success lies in understanding both “Doing Agile” as well as “Being Agile”. In […]

The post 5 Practices for an Agile Mindset appeared first on - Michael Sahota.

Categories: Blogs

Expanding Our Global Capacity with a New Office in Bangalore!

BigVisible Solutions :: An Agile Company - Wed, 10/19/2016 - 18:00

This year has been an exciting one for us as we continue to grow our footprint across the US, bring new services and solutions to our clients, and build new partnerships. We are also thrilled to announce that SolutionsIQ has a new office in Bangalore, India! As our headcount has continued to grow, we have had to figure out a new ways to connect and be happily productive. This new office on Residency Road provides a bright, colorful and inspiring environment for our teams and administrative personnel.

Here’s a peek at the new space!


Located in the heart of Bangalore, within easy reach of the major business districts, tech parks and public transportation, the office will help us continue to deliver Agile solutions and services to our growing global customer base, particularly in Asia. If you happen to be in Bangalore and would like to stop by for a tour, our new address is –

505, 5th floor
Prestige Towers
# 100/95, Residency Road
Bangalore – 560 025

For more information about SolutionsIQ India and our overseas operations and offerings, please visit

And speaking of our India office…

If you’re an Agile developer in the Bangalore area, join us in our new office for Global Day of Coderetreat Bangalore 2016 — “a day to celebrate passion and software craftsmanship”! Not sure if it’s for you? Check out this blog post by our India team!


The post Expanding Our Global Capacity with a New Office in Bangalore! appeared first on SolutionsIQ.

Categories: Companies

Achieving Business Goals with VersionOne and SAFe: An Interview with Dean Health Plan

Agile Management Blog - VersionOne - Wed, 10/19/2016 - 14:30

We recently interviewed Kel Koenig, release train engineer, at Dean Health Plan to find out why the organization selected VersionOne and the Scaled Agile Framework® (SAFe®) to accelerate its agile transformation and achieve its business goals. In the video below, Koenig talks about how the … Continue reading →

The post Achieving Business Goals with VersionOne and SAFe: An Interview with Dean Health Plan appeared first on The Agile Management Blog.

Categories: Companies

Guiding Organizational Design With SOA Principles

Leading Agile - Mike Cottmeyer - Wed, 10/19/2016 - 13:30

A couple of years ago, Mike Cottmeyer wrote a blog post on How to Structure Your Agile Enterprise.  He contended at scale we need to organize teams around capabilities.  He referenced refactoring legacy architecture into a Service Oriented Architecture (SOA).

We have proven this with many of our clients over the last couple of years.  We want to organize around products and their capabilities.  A capability is an outcome-based view of what the product does.  In other words, products, features, or services can be capabilities.  As you design your organization, you can use SOA principles to structure around these capabilities.

According to Thomas Erl’s book, “SOA Principles of Service Design,” there are 8 main SOA principles.  Below are ways you can use these principles as you transform your enterprise:

Standardized Service Contract

“Services within the same service inventory are in compliance with the same contract design standards.”

Individual parts of an engine each have detailed specifications so they will fit together consistently when assembled.  As we design an organization, we want our teams to be highly cohesive and well understood.  We want to have a governance model that defines the inputs/outputs for each stage.  This ensures consistency and predictability of value flowing through the System of Delivery.  Understood definitions of ready/done for Epics, Features, and Stories between Portfolio, Program, and Delivery teams provide the contract for work to flow through the system.

Service Loose Coupling

“Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.”

Think about an electrical outlet.  You can plug in a lamp, radio, television, or even a toaster because the interface is standardized.  You wouldn’t connect your television directly to the underlying electrical wires.  This is analogous to loose coupling of teams.  Teams agree to contracts across different capabilities in an organization to sequence or orchestrate work in parallel.  Back-end services and front end UI teams can develop capabilities simultaneously with a standardized and agreed upon interface.  When decomposing work, keeping this in mind allows for better efficiency.

Service Abstraction

“Service contracts only contain essential information and information about services is limited to what is published in service contracts.”

As we design organizations around capabilities, we want to bring together cross-functional teams of experts in that capability.  We want to define the interface for teams to interact and exchange work, but allow each team to decompose and refine their own work.  Teams require autonomy to self-organize and determine the best way to accomplish their work.  Other parties don’t need to know how they do their work, just that it returns the expected result every time.

Service Reusability

“Services contain and express agnostic logic and can be positioned as reusable enterprise resources.”

As we look across the organization, we want to identify areas of reuse.  For example, many different products utilize the services layer to localize business logic.  Forming teams around such capabilities allows for optimized expertise of the platform and eliminates the need to spread this knowledge across every team.  While small team Scrum may advocate full cross functional teams, as you scale in larger organizations, this becomes impossible due to size, complexity, and sheer number of different technologies and domains.  As in SOA, we monitor for bottlenecks and can optimize flow based on demand.

Service Autonomy

“Services exercise a high level of control over their underlying runtime execution environment.” 

Teams need to be stable and have local autonomy to make decisions and do the work requested.  We want to decouple systems and environments to allow continuous delivery and break dependencies to allow these teams to be successful.  Over time, independent funding of teams is possible, allowing for true agility.

Service Statelessness

“Services minimize resource consumption by deferring the management of state information when necessary.”  

In SOA, statelessness means that a service doesn’t need to know or care about previous calls.  It can do the work it needs to do with the information provided.  Applied to organizational design, we want teams to be autonomous and have knowledge of their own work.  Build your team structure to eliminate or minimize dependencies.  Require well-defined requests as input to the team so they have the clarity required to take it and run.  This means no dependencies or reliance on other teams.

Service Discoverability

“Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted.” 

Defining a clear end state vision for your organization is crucial for reaching organizational agility.  It ensures everyone is on the same page and working towards the same goals.  Defining the structure, governance, and metrics to measure progress is step one in any transformation.  A transparent roadmap and plan ensures teams understand the organizational design and how work needs to flow through the system.

Service Composability

“Services are effective composition participants, regardless of the size and complexity of the composition.”

The concept of service composability is taking a large problem and breaking it into smaller, more manageable chunks.  In organizational design, this speaks to organizing in vertical structures that progressively decompose business value.  Use a multi-tiered governance model to refine work into smaller pieces so the appropriate team can carry out the work (e.g., Epic to Feature to Story to Task).  This also allows for adaptability and flexibility as your market or organization changes.

Organizational design is complex and one size definitely does not fit all.  It requires working with the client and understanding their unique end state.  These ideas are by no means comprehensive, but can help guide towards the path of Organizational Agility.

The post Guiding Organizational Design With SOA Principles appeared first on LeadingAgile.

Categories: Blogs

Monthly Meetup – Managing for Happiness with Jurgen Appelo

Agile Ottawa - Wed, 10/19/2016 - 12:28
Jurgen Appelo a TED speaker, author and a past software menager will be in Ottawa for his book tour. We are very lucky to have him at our monthly meetup. If you manage a team then this is for you.   … Continue reading →
Categories: Communities

The Simple Leader: The Big Three

Evolving Excellence - Wed, 10/19/2016 - 10:31

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen

Things which matter most must never be at the mercy of things which matter least.
– Johann Wolfgang von Goethe

Like most people, I maintain a fairly long to-do list of personal and professional projects. It’s a few pages long—especially the honey-do portion. Because the list can be intimidating, I need a good strategy to tackle it. Going about it sequentially isn’t appropriate, since the tasks have varying levels of importance and time sensitivity, so each morning, I take a few moments to review my list and decide on the “Big Three” tasks that I want to get accomplished that day. Just three—no more, no less. Sometimes, one of the three may only take ten minutes, but if it rises to the importance of being one of the top three, then it deserves a spot. Maybe I’ll have time to work on a fourth task during the day, but I won’t include it on the list. By limiting the number to just three, you are forced to prioritize and focus on getting the best return in the short period of just one day.

The Big Three become the focus for the day, and I list them in my journal to ensure I stay on track. I try very hard not to insert another priority that may arise during the day, unless it absolutely, positively has to be there. (If such grenades are being launched into your schedule on a regular basis, then you might have other organizational or process issues to deal with.)

At the end of the day, I reflect on the day’s activities, including the Big Three. If I did not finish one of them, I try to understand what happened and what barriers I encountered. Did I underestimate the scope of a task? Was I distracted or interrupted? Did a different high priority task “grenade” get lobbed into my day? If so, why? Was it truly more important, or just more interesting? After figure out the barriers, I try to put countermeasures into place to do better next time. Through this process, I’ve learned a lot about myself.

I’ve used this Big Three method for nearly ten years and although it is simple, it has probably created the largest boost in my productivity out of anything I have tried. It is amazing how much you can get done over a week, month, or year if you just finish three key tasks every day.

Categories: Blogs

Links for 2016-10-18 []

Zachariah Young - Wed, 10/19/2016 - 09:00
Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.