Skip to content

Feed aggregator

Getting the Best out of Scrum

Scrum Expert - Mon, 09/29/2014 - 19:30
The best known project management framework with an Agile approach is Scrum. For something that is relatively simple to understand there is a lot of hype surrounding it. But why? This video explains: * What Scrum is and more importantly what Scrum is not? * Is Scrum too simplistic or is that its strength? * Can you run a project using Scrum or is it just for product development? * How do you scale Scrum to work in complex situations and environments? * How does Scrum relate to other methods and approaches? * Are Scrum certifications worth ...
Categories: Communities

The Future of Jobs

J.D. Meier's Blog - Mon, 09/29/2014 - 17:46

Will you have a job in the future?

What will that job look like and how will the nature of work change?

Will automation take over your job in the near future?

These are the kinds of questions that Ruth Fisher, author of Winning the Hardware-Software Game, has tackled in a series of posts.

I wrote a summary post to distill her big ideas and insights about the future of jobs in my post:

The Future of Jobs

Fisher has done an outstanding job of framing out the landscape and walking the various arguments and perspectives on how automation will change the nature of work and shape the future of jobs.

One of the first things you might be wondering is, what jobs will automation take away?

Fisher addresses that.

Another question is, what new types jobs will be created?

While that’s an exercise for the reader, Fisher provides clues based on what industry luminaries have seen in terms of how jobs are changing.

The key is to know what automation can and can’t do, and to look at the pattern of work in terms of what’s better suited for humans, and what’s better suited for machines.

As one of my mentors puts it, “If the work can be automated, it’s not human.”

He’s a fan of people doing creative, non-routine work, where they can thrive and shine.

As I take on work, or push back on work, I look through a pretty simple lens:

  1. Is the work repetitive in nature? (in which case, something that should be automated)
  2. Is the work a high-value activity? (if not, why am I doing non high-value activities?)
  3. Does the work create greater capability? (for me, the team, the organization, etc.)
  4. Does the work play to my strengths? (if not, who is a better resource or provider.  You grow faster in your strengths, and in today’s world, if people aren’t giving their best where they have their best to give, it leads to a low-impact team that eventually gets out-executed, or put out to Pasteur.)
  5. Does the work lead to world-class impact?  (When everything gets exposed beyond the firewall, and when it’s a globally connected ecosystem, it’s really important to not only bring your A-game, but to play in a way where you can provide the best service in the world for your specific niche.   If you can’t be the best in your niche in a sustainable way, then you’re in the wrong niche.)

I find that by using this simple lens, I tend to take on high-value work that creates high-impact, that cannot be easily automated.  At the same time, while I perform the work, I look for way to turn things into repetitive activities that can be outsources or automated so that I can keep moving up the stack, and producing higher-value work … that’s more human.

Categories: Blogs

Introducing SAFe for Lean Systems Engineering Big Picture 0.21

Agile Product Owner - Mon, 09/29/2014 - 17:41


In an earlier post, we announced the development of a new solution framework: SAFe for Lean Systems Engineering (SAFe LSE for short). Work continues at a pretty good pace, and the team (mostly Dean, Harry, Inbar, Alex, Regina so far) have been pretty busy putting up the new site, developing content, and of course, working on the Big Picture for SAFe LSE.

As we often discuss in SPC class, the BP serves as the domain model for the framework, as it it identifies the people that do the work, their major activities, and the work products that capture decisions and help guide the flow of work.

To that end, attached is “v 0.21″ of the SAFe LSE BP, being the 21st internal revision of this diagram. It’s far from done (SAFe reached over 100 revs before I stopped counting) but we think it tells an adequate story to start with. Of course, it isn’t fully self-explanatory, for that we need content and the website, but we think those building big complex systems can get an idea where we are headed with this version.

SAFe for Lean Systems Engineering Big Picture v0.21

SAFe for Lean Systems Engineering Big Picture v0.21

As for the near-future roadmap, we will go live with a preview version sometime in November. That one will be fully open for comments, so all can participate in adding value and criticism, as the case may be.

We do look forward to your input, and be assured that we have now fully committed to this initiative, so there will be a first GA release of SAFe for Lean systems Engineering sometime in 2015.

– Dean

PS: If you check the earlier post, you’ll see that Manifesto, which will also be elaborated with hyperlinked SAFe LSE principles, has also been updated, based on a lot of feedback we have garnered so far

PPS: We are also building a new 3-day training course:

Leading SAFe LSE: Leading Lean Systems Development with 
SAFe for Lean Systems Engineering.

The first version of this course will be delivered the first week in February, in the Boulder training center. We should have that course available for registration later this week.

Categories: Blogs

Scale Agile With Small-World Networks Posted

Johanna Rothman - Mon, 09/29/2014 - 16:59

I posted my most recent Pragmatic Manager newsletter, Scale Agile With Small-World Networks on my site.

This is a way you can scale agile out, not up. No hierarchies needed.

Small-world networks take advantage of the fact that people want to help other people in the organization. Unless you have created MBOs (Management By Objectives) that make people not want to help others, people want to see the entire product succeed. That means they want to help others. Small-world networks also take advantage of the best network in your organization—the rumor mill.

If you enjoy reading this newsletter, please do subscribe. I let my readers know about specials that I run for my books and when new books come out first.

Categories: Blogs

September Dallas Recap: Integrating UX and Agile

DFW Scrum User Group - Mon, 09/29/2014 - 16:57
This month was focused on one of the challenges commonly faced in agile adoptions: how to integrate UX and agile. We saw many new faces at our meeting, which confirmed what a hot topic this is. David Belcher, Director of … Continue reading →
Categories: Communities

Product Management for Kanban Class Curriculum

The second of our new role-based training classes focuses on replenishing your kanban system. We look at the risk management typically undertaken by product managers. Kanban offers very elegant solutions to the problems of large backlog management and prioritization. For anyone who has to decide what to work on now, what to leave until later and what to discard altogether, this is the class for you. If you want to understand how to select work for your kanban system, how to schedule it, how to sequence it and how to define classes of service to control the flow of work through the system, then this is the class for you. This class includes coverage of so called "upstream Kanban" and Real Option Theory. You'll learn to stop using the term "backlog" except for large projects with defined scope, and how to understand a "pool of ideas" as a set of options to be developed or discarded. You'll learn how to filter options based on risk assessment, how to hedge risk with capacity allocation, and how to schedule and select work, pulling it into the kanban system at the optimal time.

This new curriculum is scoped within the Modern Management Framework and will be available in 2-day class format at the Advanced Practitioner level with the LeanKanban University curriculum structure. Product Management for Kanban classes will be available publicly and privately from October 1st 2014 from David J. Anderson & Associates. From November 1st, and Accredited Advanced Kanban Trainer (AAKT) will be able to offer the class through the LeanKanban University certified training program.

read more

Categories: Companies

Online Education

Growing Agile - Mon, 09/29/2014 - 15:00

We train people all the time. The topics vary from Scrum Training to learning how to prioritise. Over the last 3 years we learned that we can’t just stand in front of a bunch of people and lecture to them. Well we can, but we’re doing them a disservice if we do. We have done a lot of reading into how people learn and what techniques to use to maximise learning during a course. Most recently we have been thinking about the online education platform. It’s a booming business – but can you learn as well online as you can in person? Let me talk you though our teaching education…

Our research introduced us to Training From the Back Of The Room (TFTBOTR) by Sharon Bowman. The basics of this was that to increase retention you should try and teach something in various ways. Repetition is key, as well as getting the students to do things and talk, rather than just the trainers talking. We fully embraced this and converted all our training use a 4C template (you can download it here).

Next we started thinking about duration of the course and training. In our experience, spending 2 days on a course does not convert to 2 days of knowledge. Usually people are so tired by day 2 that we absorb very little. 1 day of training is ok, but 2-4 hours is even better. Based on this, we then converted a few of our longer training courses into smaller 2-4 hour interactive workshops.

So how do we translate highly interactive Training From The Back Of The Room to an online medium? Most online courses we have seen are simply videos. Some have talking heads, some just have voice, and some have voice with powerpoint. Exactly the opposite of our TFTBOTR learnings. We decided to look at a blended approach. What would happen if we structured each online section of the course like a 4C plan?

Our first attempt looks something like this:

  • A short 5 min exercise to involve you with the topic. This involves writing and thinking. This is a Connection (C1) activity.
  • A short 3-8 min video with us teaching the topic. This involves listening. This is a Content (C2) activity.
  • Additional reading (mostly blog posts) and video (like a TED talk) for you to watch. This involves reading. This is also Content (C2) activity.
  • A few powerful questions for you to answer in your journal. This involves applying the knowledge to your work environment and writing it down. This is a Concrete Practice (C3) activity.
  • A technique or experiential game to use with your teams. This involves doing and talking. This is a Concrete Practice (C3) activity.
  • A challenge. This varies between talking, doing, writing, reflecting. This is a Conclusion (C4) activity.

We feel that if you follow each of the steps you might get very close to an in-person training experience. Our first course on Leadership has been published. The section on Listening is available for free. Take a look to see how you think this compares to in person training.

If you would like to take the whole course – join our newsletter and receive a 50% discount once we have launched in October!

Here are some TED talks on online education and why you should care icon smile Online Education

Daphne Koller: What we’re learning from online education

Salman Khan: Lets use video to reinvent education

Categories: Companies

Agile and Predictability

James Shore - Mon, 09/29/2014 - 10:00
29 Sep 2014 James Shore/Blog

Over on the AgilePDX mailing list, there's an interesting conversation on making predictions with Agile. It started off with Michael Kelly asking if Agile can help with predictability. Here's my response:

It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.

Software is inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have.

One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff in XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*) They can and do provide reliable predictions.

Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions just as well as two-star teams can, but estimating and predicting has a cost, and those predictions often have no real value in the market. They often choose not to incur the waste of making predictions.

So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability the organization wants.

I describe the "how to" of making predictions with Agile in "Use Risk Management to Make Solid Commitments".

*The error-bar numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.

Categories: Blogs

R: Filtering data frames by column type (‘x’ must be numeric)

Mark Needham - Mon, 09/29/2014 - 07:46

I’ve been working through the exercises from An Introduction to Statistical Learning and one of them required you to create a pair wise correlation matrix of variables in a data frame.

The exercise uses the ‘Carseats’ data set which can be imported like so:

> install.packages("ISLR")
> library(ISLR)
> head(Carseats)
  Sales CompPrice Income Advertising Population Price ShelveLoc Age Education Urban  US
1  9.50       138     73          11        276   120       Bad  42        17   Yes Yes
2 11.22       111     48          16        260    83      Good  65        10   Yes Yes
3 10.06       113     35          10        269    80    Medium  59        12   Yes Yes
4  7.40       117    100           4        466    97    Medium  55        14   Yes Yes
5  4.15       141     64           3        340   128       Bad  38        13   Yes  No
6 10.81       124    113          13        501    72       Bad  78        16    No Yes

filter the categorical variables from a data frame and

If we try to run the ‘cor‘ function on the data frame we’ll get the following error:

> cor(Carseats)
Error in cor(Carseats) : 'x' must be numeric

As the error message suggests, we can’t pass non numeric variables to this function so we need to remove the categorical variables from our data frame.

But first we need to work out which columns those are:

> sapply(Carseats, class)
      Sales   CompPrice      Income Advertising  Population       Price   ShelveLoc         Age   Education 
  "numeric"   "numeric"   "numeric"   "numeric"   "numeric"   "numeric"    "factor"   "numeric"   "numeric" 
      Urban          US 
   "factor"    "factor"

We can see a few columns of type ‘factor’ and luckily for us there’s a function which will help us identify those more easily:

> sapply(Carseats, is.factor)
      Sales   CompPrice      Income Advertising  Population       Price   ShelveLoc         Age   Education 
      FALSE       FALSE       FALSE       FALSE       FALSE       FALSE        TRUE       FALSE       FALSE 
      Urban          US 
       TRUE        TRUE

Now we can remove those columns from our data frame and create the correlation matrix:

> cor(Carseats[sapply(Carseats, function(x) !is.factor(x))])
                  Sales   CompPrice       Income  Advertising   Population       Price          Age    Education
Sales        1.00000000  0.06407873  0.151950979  0.269506781  0.050470984 -0.44495073 -0.231815440 -0.051955242
CompPrice    0.06407873  1.00000000 -0.080653423 -0.024198788 -0.094706516  0.58484777 -0.100238817  0.025197050
Income       0.15195098 -0.08065342  1.000000000  0.058994706 -0.007876994 -0.05669820 -0.004670094 -0.056855422
Advertising  0.26950678 -0.02419879  0.058994706  1.000000000  0.265652145  0.04453687 -0.004557497 -0.033594307
Population   0.05047098 -0.09470652 -0.007876994  0.265652145  1.000000000 -0.01214362 -0.042663355 -0.106378231
Price       -0.44495073  0.58484777 -0.056698202  0.044536874 -0.012143620  1.00000000 -0.102176839  0.011746599
Age         -0.23181544 -0.10023882 -0.004670094 -0.004557497 -0.042663355 -0.10217684  1.000000000  0.006488032
Education   -0.05195524  0.02519705 -0.056855422 -0.033594307 -0.106378231  0.01174660  0.006488032  1.000000000
Categories: Blogs

Team Genetics

Agile Tools - Mon, 09/29/2014 - 07:41


Today I was listing to “The Splendid Table”, a great cooking show on NPR. They were talking about variation in growing heirloom tomatoes. Somehow, that got me thinking about agile teams (probably time to see the therapist again). It occurred to me that ideas like Agile are memes.

Richard Dawkins defined a meme as “an idea, behavior, or style that spreads from person to person within a culture.” and Agile certainly fits that definition. Agile has spread from obscurity to worldwide acceptance within 20 years. In another 20 years I fully expect that waterfall, plan driven methods will be nothing but a footnote in the history books. Despite some early prognostications to the contrary, Agile has grown at a very healthy rate over the last several years.

“Richard Dawkins invented the term ‘memes’ to stand for items that are reproduced by imitation rather than reproduced genetically.”

While much of the credit belongs to the teams that actually do the hard work of making a new process work, there is also the business that has arisen around evangelizing and introducing Agile to companies that deserves a great deal of the credit. Agile training and consulting has done a remarkable job of spreading the meme throughout the software development world.

I think there are characteristics of Agile training that have made Agile “sticky” as a meme. Much of the Scrum certification is based on plenty of hands-on exercises. Training and certification has yielded a decent business. I’m not sure if anyone has the numbers, but I’d be surprised if it wasn’t a multi-million dollar enterprise worldwide. Strangely enough, much of that spreading has been through imitation. There is no shared agenda for the training, much of it is simply imitated from trainer to trainer.

When trainers and others spread the meme they are like Johnny Appleseed sowing Agile ideas across fertile corporate soil.

Genes change with each generation, and so do ideas. They go through a mixing and blending each time they are shared. Parts of the idea are forgotten, other new ideas are grafted on. Soon the original idea is unrecognizable. I think that’s kind of what has happened with XP. Extreme Programming originally contained a collection of ideas that were very potent. Things like pair programming, continuous integration and others all served as core ideas within XP. Over time, those ideas have been co-opted and found their main expression in Scrum. Today, almost no one trains teams in XP, Scrum is the dominant process that is trained and introduced to teams.

“Memes do this through the processes of variation, mutation, competition, and inheritance, each of which influence a meme’s reproductive success.”

So too does Agile. In recent years methods like Kanban and ideas like No Estimates have arisen and are becoming a meaningful part of the software development landscape. These are evolutions of the Agile meme. Agile is evolving, I wonder where it will go next…

Filed under: Agile, Lean, Process, Scrum, Swarming, XP Tagged: Agile, evolution, Extreme Programming, Kanban, meme, no estimates, Process, software development, XP
Categories: Blogs

Dazzle Your Audience By Doodling

Xebia Blog - Sun, 09/28/2014 - 11:29

When we were kids, we loved to doodle. Most of us did anyway. I doodled all the time, everywhere, and, to the dismay of my mother, on everything. I still love to doodle. In fact, I believe doodling is essential.

The tragedy of the doodle lies in its definition: "A doodle is an unfocused or unconscious drawing while a person's attention is otherwise occupied." That's why most of us have been taught not to doodle. Seems logical, right? Teacher sees you doodling, that is not paying attention in class, thus not learning as much as you should, so he puts a stop to it. Trouble is though, it's wrong. And it's not just a little bit wrong, it's totally and utterly wrong. Exactly how wrong was shown in a case study by Jackie Andrade. She discovered that doodlers have 29% better recall. So, if you don't doodle, you're doing yourself a disservice.

And you're not just doing yourself a disservice, you're also doing your audience a disservice. Neurologists have discovered a phenomenon dubbed "mirror neurons." When you see something, the same neurons fire as if you were doing it. So, if someone shows you a picture, let's say a slide in a presentation, it is as if you're showing that picture to yourself.

Wait, what? That doesn't sound special at all, now does it? That's why presentations using only slides can be so unintentionally relaxing.

Now, if you see someone write or draw something on a flip chart, dry erase board or any other surface in plain sight, it is as if you're writing or drawing it yourself. And that ensures 29% better recall. Better yet, you'll remember what the presenter wants you to rememeber. Especially if he can trigger an emotional response.

Now, why is that? At EUVIZ in Berlin last month, I attended a presentation by Barbara Siegel from Look2Listen that changed my life. Barbara talked about the latest insights from neuroscience that prove that everyone feels first and thinks later. So, if you want your audience to tune in to your talk, show some emotion! Want people to remember specific points of your talk? Trigger and capture emotion by writing and drawing in real-time. Emotion runs deep and draws firm neurological paths in the brain that help you recreate the memory. Memories are recreated, not stored and retrieved.

Another thing that helps you draw firm neurological paths is exercise. If you get your audience to stand up and move, you increase their brain activity by 7%, hightening alertness and motivation. By getting your audience to sit down again after physical exercise, you trigger a rebalancing of neurotransmitters and other neurochemicals, so they can use the newly spawned neurons in their brain to combine into memories of your talk. Now that got me running every other day! Well, jogging is more like it, but hey: I'm hitting my target heart-rate regularly!

How does this help you become a better public speaker? Remember these two key points:

  1. At the start of your speech, get your audience to stand up and move to ensure 7% more brain activity and prime them for maximum recall.
  2. Make sure to use visuals and metaphors and create most, if not all, of them in real-time to leverage the mirror neuron effect and increase recall by 29%.
Categories: Companies

Broadcast Communication

Agile Tools - Sun, 09/28/2014 - 04:56


In the agile development community, we are all hip to the notion of two way communication. It can be via any mechanism you choose: email, instant messaging, smoke signals or the hands-down, all-time winner – face to face. That’s fantastic, but there is another form of communication that we can develop: one-way communication.

What’s the value of that, you ask? Isn’t two way communication a lot better? The answer is yes, two way communication is great and has it’s place, but one way communication has a different purpose – one that agile teams should learn to develop as well. In fact, most agile teams don’t do very well at the one way communication beyond the team at all.

Let me explain: One way, or broadcast communication doesn’t require any response. You just shout out the news and go about your business. Now of course if there is no one to hear the news, then it really doesn’t make much difference (if a tree falls in the forest…). However in the case of working on a team, there is usually someone around. Broadcasting simply shares information with absolutely no expectation of any information or reply in return. It’s all giving and no receiving. Others can get the information and then act accordingly without ever engaging in dialog.

Some examples of one way communication include: status reports, information radiators: including burndown charts, kanban boards, etcetera. There are tools that promote one way communication such as Twitter and Yammer. I suppose even a wiki or blog qualifies too.

There is one other thing about broadcast communication that I like, especially when it comes to swarming. One way communication removes any expectation of compliance. When you broadcast information, the receivers get to decide what they want to do with it. There is no expectation of any sort of action. Commands are weakened or non-existent with this type of communication. That’s a good thing if you are swarming.

A few sentences back, I made the claim that Agile teams aren’t very good at broadcasting information beyond the team. Many of the teams that I work with tend to be very inward facing. The communication is rich between team members, but it’s very sparse if you are outside the team. This may also be a reflection of the hierarchical nature of many of the companies I’ve worked with. Teams need to take advantage of every mechanism they can find to radiate information outside the team. Some opportunities include:

  • The Scrum of Scrums or other program or portfolio meetings
  • Information radiators OUTSIDE the team. Broadcast doesn’t work if everyone has to come to you to get the message.
  • Attending other forums, other teams status meetings
  • Status reporting – yes, status reports are the root of all evil, but they are a form of one way communication.

If you aren’t using one way broadcast, give it at try. It’s a powerful communication tool – and essential to promote swarming.

Filed under: Agile, Process, Scrum, Swarming, Teams Tagged: communication, information radiators, one way broadcast, Swarming
Categories: Blogs

1. Capitalisation target; 2. ???; 3. Profit!

The organisation has a capitalisation target.

Everyone encourages managers to increase the capitalisation of their areas.  If they don't, they won't get funded.

The simplest way to increase capitalisation rate is simply changing numbers in spreadsheets.  This is mostly independent of whether or not the work is creating an asset because it's easier to move a number than it is to argue.
I've been told that from a corporate finance perspective, the priority is:
  1. Appropriate accounting of capital and operating expense
  2. Effective use of financial investment to achieve strategic goals
"How might we meet our capitalisation target?" is a question that leads organisations away from either of those goals.
Instead, if we want appropriate accounting, we might ask..."How might we improve the accuracy of our accounting?"This might lead to...
  • Training sessions, guides, etc. on appropriate capitalisation
  • Integration with tooling
  • Only assessing capitalisation after delivery of the assets.  That is, operating using OPEX and only journalling to CAPEX upon release.  I'd call this "as-built accounting".
Instead, if we want to have more effective financial investment, we would just ask that question..."How might we be more effective with our financial investment?"This might lead to...

  • Clearer communication of strategic intent
  • Collective prioritisation of the portfolio
  • Smaller batch sizes to allow for staged investment
  • More sophisticated ways of assessing investments (e.g. Cost of Delay)
Categories: Blogs

Using the Understanding of When SAFe Is Heavy Is How to Use It Properly a Organizations Smaller Than It Was Designed For

NetObjectives - Sat, 09/27/2014 - 21:24
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe  I’ve had a very interesting few weeks. At Net Objectives we’ve always put the customer first, even if this meant not offering a technology we were certified to teach. This has also made us unpopular with several of the certifying bodies that we’ve worked with.  The Scrum Alliance didn’t like when we said you needed...

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

What Is It That Can Make SAFe Heavy?

NetObjectives - Sat, 09/27/2014 - 20:24
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe  Many of the detractors of SAFe say it is heavy. But it is only heavy if it is more than is needed. For example, prior to 3.0, SAFe had a Hardening, Innovation and Planning Sprint.  People would say "hardening" (i.e., when you just work on bugs) is not an Agile concept.  I would say, "when you need it, it is."  In...

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

SAFe Is Not Popular Because of Great Marketing, It’s Popular Because It Fills a Need

NetObjectives - Sat, 09/27/2014 - 19:52
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe  SAFe has erupted on the software development scene not due to fabulous marketing as its detractors have claimed, but rather due to the fact that it addresses a need most practitioners in large organizations have intuitively felt and most in the Agile community has denied. The patience of those wanting to become more...

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

Addressing the Needs of Agile at Scale

NetObjectives - Sat, 09/27/2014 - 19:12
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe  Net Objectives has been assisting large scale clients become Agile for almost a decade.  This blog describes the key components of this thinking and how they address the main causes of waste at scale. Our next blog will describe how this thought process can be thought of as the essence of the Scaled Agile Framework. ...

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

Main Causes of Waste at Scale

NetObjectives - Sat, 09/27/2014 - 18:10
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe  Much of the problems we face now are due to solutions we had at a team level that do not solve the problems at the cross-team and enterprise level.  This blog discusses what these wastes are which is our first step in avoiding them. I have long maintained that the Lean Mantra of “eliminate waste” is a red herring in...

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

How Where an Approach Starts Seems to Influence it Forever

NetObjectives - Sat, 09/27/2014 - 16:41
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean-Agile and SAFe Those who cannot remember the past are condemned to repeat it.  George Santayana The more things change the more things stay the same. Jean-Baptiste Alphonse Karr While I’ve always had an interest in history, I’ve never considered myself to be much of a student of it.  I’ve mostly found it interesting and useful...

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

Different Sized Organizations Have Different Dynamics

NetObjectives - Sat, 09/27/2014 - 15:55
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe  Over the past 16 years I have worked with scores of companies and talked to literally hundreds more.  Different size organizations have differing dynamics.  This might appear obvious (it actually does to any systems thinkers) but it continues to surprise me the number of folks denying or just ignoring this...

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

Knowledge Sharing

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