Skip to content

Feed aggregator

Agile Culture

Scrum Expert - Tue, 09/30/2014 - 15:58
If you asked software developers about Agile, there are chances that a majority will discuss it with words like “Scrum”, “sprints” or “retrospectives”. However Agile is not just a collection of techniques and practices, but it is more a state of mind or a culture. This is the topic of this book written by Pollyanna Pixton, Paul Gibson and Niel Nickolaisen. All the people and values aspects of Agile software development are discussed in this book that provides both conceptual material and real life stories. This is a book that I ...
Categories: Communities

Agile Slovenia, Ljubljana, Slovenia, October 10 2014

Scrum Expert - Tue, 09/30/2014 - 14:39
Agile Slovenia is a one day conference focused on Agile and Scrum topics that take place in Ljubljana. Agile Slovenia is an event where you can turn theory in action, meet agile people, listen to agile pioneers, expand your knowledge. It features both local and international Agile experts. In the agenda you can find topics like “Shifting from manufacturing product to creating a service”, “Complex Projects aren’t planable but controllable”, “There’s no such thing as an agile contract”, “How Agile Coaches help us win – the Agile Coach role at Spotify”, ...
Categories: Communities

Large Scale Scrum (LeSS)

Agile World - Venkatesh Krishnamurthy - Tue, 09/30/2014 - 13:52

Last week, I had the opportunity to speak about Large Scale Scrum (LeSS) at Agile PM meet up group  in Melbourne.  It was really an honor to speak with such an incredibly experienced, knowledgeable audience. At the end of the session, we had very engaging Q&A.

As part of the session, I shared some of the challenges of  scaling Agile and possible solutions as well. One of the solution being, applying the Large Scale Scrum(LeSS). 

Based on my experience of working on several large scale Agile projects, I have come to realize the following 4 types of challenges common across large enterprises.  They are People, Process, Tools/Technology and Org Structure/Culture. 

I have summarized the challenges into this diagram

image

Even though these challenges are common in small Agile projects but gets amplified while scaling Agile.

The popular  Scaling Frameworks are as follows:   Spotify,  XScale, SAFe, DAD (Disciplined Agile Delivery).

image

In addition to the above,  Large Scale Scrum(LeSS) by Craig Larman is popular as well.  I have personally applied this while working with Craig Larman during 2006 at Valtech India. LeSS and LeSS Huge are two variants for large scale projects.  LeSS huge can be depicted as shown in the diagram below:

image

LeSS is based on some of the proven principles around Queuing Theory,  Systems Thinking  and Empirical Process Control  as shown below.

image

If you want to learn more about  applying Large Scale Scrum on your projects, do drop me an email and happy to share the ideas.

Categories: Blogs

15 Useful Pacts for Agile Teams: An Agile Team Creed

Agile Management Blog - VersionOne - Tue, 09/30/2014 - 13:49

The Agile Manifesto values “Individuals and Interactions” over “Process and Tools.”  I suspect it was no accident that this was listed first.  Lack of communication, miscommunication, or the mistaken presumption that communication has occurred, are the root cause of many problems.  Yet, we still focus much discussion on the process and tools.

  • When and how do you conduct a certain Scrum ceremony?
  • Are you practicing pure Scrum?
  • Which agile tools do you use and why?
  • How do you use the tool?
  • What agile metrics are you using and how?
  • What best practices exist?
  • And lots more concerns and questions about how to “do” process…

However, most all change transformations to “be” agile struggle with organizational culture and many organizations and teams continue to fail to reach their full potential because of issues related to “individuals and interactions.”

Teams are the heartbeat of agile development.  It’s the people that produce business success.  Even when the organizational culture embraces agile values, the teams must also address their individuals and healthy interactions among them to maximize value.  This takes time and effort to mature.  I find we mistakenly assume that since people know each other already and even “behave” nicely, they think they can skip over the team-building activities.

Simply gathering individuals together and assigning them the label of “team” does not make a team.  Each team is comprised of unique personalities and thus there is no cookie-cutter best answer for every team.  Each team must find its own way and navigate the uniqueness of each individual to determine the best way to handle interactions that work for their team dynamic.  There should be “pacts” that everyone on the team agrees to.  If there are dysfunctions (egos, prima donnas, passive aggressive behavior, apathy, poor listening skills, a presumed hierarchy, and so on), then the challenge is an order of magnitude that’s much more difficult.  Each team is a unique, dynamic system, subject to changing moods and their environment.

Sadly, some agile teams never evolve beyond a collection of individuals who meet together at the prescribed Scrum ceremonies and then return to work independently with a focus on their individual tasks only.  Maybe the ability to track their work has improved, but they have failed to recognize and harness the true potential that comes from working as a high-performing team.  Perhaps you have seen teams who are full of energy and so you recognize the power of teams?  So, why do some teams never get there?  There are multiple factors that influence agile and Scrum teams.

Let’s assume that the organization’s leadership values the power of teams and has a supportive culture and vision in play.  So what can be done within the team to ensure that it sets a solid foundation for growth and success?

During the team forming stage, it is important for the team members to openly discuss behaviors and expectations.  There is great value in recording those discussions as a reminder to the members when they do encounter problems.  But, they need to dive deeply into what each member truly believes and feels.  Because what you believe and how you feel directly determines how you will behave.  These team discussions must go beyond the process-mechanics agreements such as what time to meet.  They need to communicate something more of an “agile team creed” or list of pacts they make with one another. Team members must be comfortable sharing their fears and concerns.

Having an agile team creed is a great starting point for deep team discussions to root out true beliefs.  It captures cultural expectations and behaviors for the team which I believe lay the foundation for a great agile team.  Here is my list of 15 useful pacts agile teams can make.  I call it the Agile Team Creed.

Agile Team Creed

Has your team had these deep conservations about what they believe?  Would they agree with these items as part of their Agile Team Creed?  If not, why?  Perhaps, it reveals a cultural issue that needs attention.

Categories: Companies

New Connections Functionality Now Available

LeanKit’s new Connections functionality has been released to all Portfolio Edition accounts. Find out how this enables you to track and manage work distributed across multiple teams and boards — without losing sight of the details. For some time now, LeanKit has provided the ability to create drill-through relationships. This functionality enabled you to establish parent-child associations between a […]

The post New Connections Functionality Now Available appeared first on Blog | LeanKit.

Categories: Companies

Swarming Context

Agile Tools - Tue, 09/30/2014 - 07:12

Rail_Bridge_Swarm_of_Starlings._-_geograph.org.uk_-_124591

The application of Swarming as a method can be broken down into four main contexts. For each context the process of swarming is different. Allowing for different contexts makes sense, because we really can’t expect the same process to work equally well in every situation. Even the simplest animals are able to exhibit variations in behavior based on the context, so why shouldn’t our processes? We change our behavior to match the circumstances. That is, unless we are using fixed methods like Scrum or Kanban. If you are using fixed methods, the proscription is to treat the process in a fractal fashion, repeating it everywhere. Practically speaking, by having only one process these methods ignore the context.

So what are the four contexts of Swarming? Here they are in no particular order:

  • Emergencies
  • Shifting Gears
  • Innovation
  • Building

Emergencies represent the simplest context for swarming. When a crisis occurs, it’ all hands on deck. Everyone joins the conversation and brings whatever specific expertise they have to the party. The group self-organizes to enable those present to contribute to solving the problem. You see this a lot in production operations environments when a “P1″ defect occurs or, heaven forbid, the production system goes down. When this happens, everyone swarms on the problem. Some are gathering information, some are listening and integrating the information, and some are taking action to try and remedy the situation. All of this is happening dynamically in the moment without central organization. All of these activities are critical to the success of the swarm. During a crisis, nobody is going to stop what they are doing for a standup meeting, and they sure as hell aren’t interested in seeing your Kanban board.

Shifting gears refers to when the system is in transition. The corporate ecosystems that we are all a part of are changing faster with every passing day. New products are coming to market and disrupting the old ones. It’s not enough to simply work within the existing system. You can’t keep up that way. These days corporations have to match their structure to the complexity of the environment. That’s hard, and that’s where swarming comes in. Like when honey bees form a swarm, the corporation reaches a critical mass where a new structure is necessary. Up until this point, the hive has been a stable and reliable structure, but with the presence of a new queen everything changes. A cascade of events takes place where the hive moves on. This can also happen with companies. When they reach a certain size, they can spin off subsidiaries, divisions, and even teams. We see this when teams reach critical mass and split into two teams (meiosis). On swarming teams, we use simple rules to enable groups to decide on their own when division should take place (Team size of 7 plus or minus 2). We use the swarming values and principles to help guide who works on each team – always leaning toward letting individuals decide based on where their own passions take them.

In swarming, Innovation is treated as foraging. We are foraging for new information and new ideas. In this context we are actively using our social networks to recruit new people and new ideas to our cause. This can be initiated as part of a special state (shifting gears) or it can be part of the ongoing activities of the team. When ants are foraging, they tend to follow the strongest pheromone trails to a food source. However this rule is not universal. There are ants who wander off the pheromone trail from time to time. These solitary explorers are the ones who have the unique opportunity to wander off the beaten path and potentially find rich new sources of food. So too, we want people on our team not to follow the team too closely. It’s best if they can wander off and explore side avenues and blind alleys. This isn’t something that is dictated, it’s a natural part of teams with rich diversity. People make these decisions on their own and either bring them back to the original team or they form a new team.

Building takes place when we are trying to strengthen our networks. As a team is growing it uses it’s social networks to strengthen bonds both within and without the team. This can be as simple as increasing the number of social “touches” on a team. Social touches are things like: greeting each other, going out to lunch together, supporting each other’s work. There are some people who are stronger at this than others. Some people tend to form many lightweight social contacts (which is very useful). On the other hand, there are those who only have a few deep, strong relationships. A good swarming team is composed of a healthy balance of both types of people.

In summary, swarming is used differently based on the context you are in. Understand the context, and you are prepared to take advantage of the power of swarming.

 


Filed under: Agile, Swarming, Teams Tagged: animals, building, context, emergencies, innovation, Kanban, methods, Scrum, shifting gears, Swarming, Teams
Categories: Blogs

PostgreSQL: ERROR: column does not exist

Mark Needham - Tue, 09/30/2014 - 00:40

I’ve been playing around with PostgreSQL recently and in particular the Northwind dataset typically used as an introductory data set for relational databases.

Having imported the data I wanted to take a quick look at the employees table:

postgres=# SELECT * FROM employees LIMIT 1;
 EmployeeID | LastName | FirstName |        Title         | TitleOfCourtesy | BirthDate  |  HireDate  |           Address           |  City   | Region | PostalCode | Country |   HomePhone    | Extension | Photo |                                                                                      Notes                                                                                      | ReportsTo |              PhotoPath               
------------+----------+-----------+----------------------+-----------------+------------+------------+-----------------------------+---------+--------+------------+---------+----------------+-----------+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+--------------------------------------
          1 | Davolio  | Nancy     | Sales Representative | Ms.             | 1948-12-08 | 1992-05-01 | 507 - 20th Ave. E.\nApt. 2A | Seattle | WA     | 98122      | USA     | (206) 555-9857 | 5467      | \x    | Education includes a BA IN psychology FROM Colorado State University IN 1970.  She also completed "The Art of the Cold Call."  Nancy IS a member OF Toastmasters International. |         2 | http://accweb/emmployees/davolio.bmp
(1 ROW)

That works fine but what if I only want to return the ‘EmployeeID’ field?

postgres=# SELECT EmployeeID FROM employees LIMIT 1;
ERROR:  COLUMN "employeeid" does NOT exist
LINE 1: SELECT EmployeeID FROM employees LIMIT 1;

I hadn’t realised (or had forgotten) that field names get lower cased so we need to quote the name if it’s been stored in mixed case:

postgres=# SELECT "EmployeeID" FROM employees LIMIT 1;
 EmployeeID 
------------
          1
(1 ROW)

From my reading the suggestion seems to be to have your field names lower cased to avoid this problem but since it’s just a dummy data set I guess I’ll just put up with the quoting overhead for now.

Categories: Blogs

R: Deriving a new data frame column based on containing string

Mark Needham - Mon, 09/29/2014 - 23:37

I’ve been playing around with R data frames a bit more and one thing I wanted to do was derive a new column based on the text contained in the existing column.

I started with something like this:

> x = data.frame(name = c("Java Hackathon", "Intro to Graphs", "Hands on Cypher"))
> x
             name
1  Java Hackathon
2 Intro to Graphs
3 Hands on Cypher

And I wanted to derive a new column based on whether or not the session was a practical one. The grepl function seemed to be the best tool for the job:

> grepl("Hackathon|Hands on|Hands On", x$name)
[1]  TRUE FALSE  TRUE

We can then add a column to our data frame with that output:

x$practical = grepl("Hackathon|Hands on|Hands On", x$name)

And we end up with the following:

> x
             name practical
1  Java Hackathon      TRUE
2 Intro to Graphs     FALSE
3 Hands on Cypher      TRUE

Not too tricky but it took me a bit too long to figure it out so I thought I’d save future Mark some time!

Categories: Blogs

JIRA is Not Agile

Notes from a Tool User - Mark Levison - Mon, 09/29/2014 - 22:00

Agile pyramid 2I’ve heard people say, “We started using Jira and GreenHopper, so we’re Agile now”. Similar things are said of Rally, VersionOne, LeanKit, TargetProcess, etc. In making those declarations, it’s clear that they don’t understand Agile at all.

At its core, Agile is a set of Values and Principles:

…. ·      Individuals and interactions over processes and tools ·      Working software over comprehensive documentation ·      Customer collaboration over contract negotiation ·      Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Underlying these is a mindset with a focus on self-discipline, self-organization, and adaption to change.

The Practices of Scrum (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), the Roles (ScrumMaster, Product Owner, and Development Team), and the Artifacts (Product Backlog, Sprint Backlog, and Product Increment) only help the team support the principles and achieve the goal of delivering working software.

Electronic tools (Task walls, Development Environments, …) or physical tools (Task walls, …) are only useful in so far as they provide support for those principles and practices.

If your Agile adoption starts with a tool and a scattering of practices, then the whole point has been missed and the core – the essence – of Agile needs to be carefully reviewed until that is obvious.

Categories: Blogs

The Edible Birthday

Portia Tung - Selfish Programming - Mon, 09/29/2014 - 21:33

Birthday Cake

I’m a September baby and this year, I treated my friends at work to the most scrumptious cake I’ve ever seen. What better way to remind us of transformative journeys along the Yellow Brick Road than with the Rainbow Cake by Hummingbird Cafe.

Folks ummed and ahhed at the sight of the multi-coloured layers of this beautiful cake only to be further and pleasantly surprised by the bubble gum flavoured icing as they savoured their slice.

“If I still wrote software, this would be the kind of software I’d create,” I mused, drunken on sugary goodness.

“Don’t you think that would smack of over-engineering?” remarked a fellow cake-connoisseur.

Of course, what I really meant to say is that I marvel at the thought of creating something so thoughtful and thought-provoking as the Rainbow cake. A work of exquisite (and, optionally, edible) beauty that would brighten the world and remind us of what passion, creativity and craftsmanship can produce.

All this serves as a timely reminder that we need to live our dreams to make them come true.

Here’s to enjoying the rainbows on your journey of a lifetime. Happy Birthday one and all!

Categories: Blogs

Combining PRINCE2 with Agile

TV Agile - Mon, 09/29/2014 - 20:01
PRINCE2 and Agile are now both mainstream and many organizations are combining these two approaches but with varying degrees of success. How can you benefit from linking these two approaches which, on the face of it, may not be seen as complementary? This presentation covers: * What are the relative strengths of each approach? * […]
Categories: Blogs

The Wonders of Workspaces

Pivotal Tracker Blog - Mon, 09/29/2014 - 19:43

Visibility is a wonderful thing. Making your team’s work transparent lets every stakeholder judge current status and progress at a glance. This transparency also reveals impediments – is one story blocked by another? Is something holding up progress? Are some activities turning into bottlenecks? Seeing a snapshot of a team’s current status and progress is also a conversation starter: “I have a question about this story – oh, I see that Joe, Debbie and Mary are all working on it, I will ask them”.

MPworkspace

Example multi-project workspace. Note the color coding for projects across the top of each panel & in the sidebar.

Tracker has provided visibility into individual software projects for years. But your organization probably isn’t working on one simple project. Maybe you have more than one code base for your product, for example, a back-end server, a front-end web app, a mobile app. You might have multiple versions of some of those, too. Oh, and there’s a lot of supporting work to track: DevOps activities, testing across multiple code bases, UX design. It doesn’t make sense to shoehorn everything into one project. But managing multiple projects can get pretty complicated. The beta version of Tracker offers an approach that works well for many teams that have multiple products or projects to manage: workspaces. Tracker users have the option to view and manage several Tracker projects side-by-side in their multi-project workspace. Let’s look at the multiple joys that multi-project workspaces have to offer. Improved Visibility When you create a multi-project workspace, you can load relevant panels from all your projects into one Tracker session, and see progress in all of them at a glance. If you’re working on stories in more than one project, you can see all your current stories in all projects in the My Work panel. See the screenshot above for an example My Work across multiple projects.

Select color in the single project view

Select color for a single project

Manage workspace to easily update project colors

Manage workspace

If your team currently uses a single project for all stories, and manages different tracks with epics, consider giving each track its own project. The multi-project view gives a simpler high-level view, with color coding to distinguish project panels. Click the icon at the top left of the sidebar, above the Add Story button, to manage your workspace. As well as adding and removing the Projects you would like in your workspace there, via the “add/remove projects” dialog, you can change project colors. You can also customize your colors in single project view by clicking on the color icon at the top left. Easy, Flexible Organizing Let’s say your team creates projects for your front-end code, your back-end server, a mobile app, DevOps chores, and system testing charters. You’re a tester who gets involved in all of these (yes, multi-tasking is bad, but cross-functional knowledge and involvement is good!) You add all these projects to your Tracker workspace so you can see the big picture. Tracker remembers what panels you had open the last time you used your workspace, and in what order, so you don’t need to tweak your panel layout each session. You start testing delivered stories in the front-end project, because that release is coming up soon. As you are testing, you discover a new bug in the back-end code. Without having to switch to a different Tracker view, you add a bug story to your back-end project Icebox. While looking at the back-end project’s Icebox, you realize that a bug story you entered earlier is really a problem on the front-end. You simply drag that story over to the front-end Icebox panel where it belongs. Before returning to testing your front-end stories, you see a new in-app notification. Clicking on the story in the notification, Tracker opens a story in the mobile app project. A new feature you’re keen to test has just been delivered, so you make a mental note to check that out later. A little while later, you’ve caught up with testing the front-end stories. Your next priority would be to test delivered back-end stories, but you can see nothing has been delivered yet. There is also some exploratory testing to do on the front-end, but you can see that a developer pair has been cranking through the test charters in your system testing project, so you go test that fun new mobile app feature. Managing Dependencies There are many ways a story can get blocked. It may be waiting for a design element or a change to an API. It might be blocked by a story in the same project, or one in another project. We like to make this visible by putting a “blocked” label on the story, along with a link to the story that’s blocking it. For example, if it’s waiting for a design story, the label may be “needs design”. If a delivered story can’t be accepted yet due to a dependency on another story, it gets an “accept blocked” label. The blocking story also gets a label and a link to the story it’s blocking. This information stays front and center for everyone on the team. This kind of visibility is even more crucial when multiple teams work on the same or related products.

Story dependencies made visible with labels and links to stories in other projects

Story dependencies made visible with labels and links to stories in other projects

Since Tracker allows you to search across all projects in your workspace, you can bring up all stories with a particular label. They’ll display in a panel ordered by project. Promoting Conversations Along with multi-project workspace, Tracker beta provides other features to enhance communication. Each Tracker user can customize their own settings for in-app notifications. The bell icon at the top of the page indicates the number of unread notifications. When you open a notification, you can click to open the story, regardless of what projects you currently have open. Project members can quickly get attention from others with @mentions, which get special highlighting. Then, if necessary, they can have a face-to-face conversation about the story or epic. Finding Stuff Faster When you’re involved in multiple projects, it can get hard to remember which stories are where. In Tracker’s multi-project workspace, the searches you request will retrieve matches in any of the projects in your workspace. It saves time, plus you’ll see stories in other projects that may be related.

You can search across all projects in your workspace

You can search across all projects in your workspace

I often click on a label for a quick overview of all the stories in my workspace with that label. We’ll be enhancing the ability to organize your work with saved searches in workspaces later on.

newBetaButton

Click the button to try beta!

If you haven’t experienced the joys of the multi-project workspace, click the button at the top of your project page to switch to Beta. When you get there, check out the Beta Overview panel (accessed via the Help & Updates menu at the top right of your Tracker window) to see how to configure your workspace. Enjoy improved visibility into project progress and impediments, and better communication with your teammates. In the coming weeks, we will be adding more capabilities including the ability to create multiple workspaces, each with a different set of projects. Are you already using a multi-project workspace? We’d love to hear how you’re making the most of this new feature. Please comment and share your experiences.

The post The Wonders of Workspaces appeared first on Pivotal Tracker.

Categories: Companies

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

Hi,

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

Knowledge Sharing


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