Skip to content

Feed aggregator

January Newsletter: Future of Lean, DeGrandis Joins LeanKit, New Help Center, and More

Here’s the January 2015 edition of the LeanKit monthly newsletter. Make sure you catch the next issue in your inbox and subscribe today. What is the Future of Lean? Dan Jones and Jim Womack, founding fathers of the Lean movement, discuss the current state, evolution, and future of Lean thinking. Hear their thoughts about the […]

The post January Newsletter: Future of Lean, DeGrandis Joins LeanKit, New Help Center, and More appeared first on Blog | LeanKit.

Categories: Companies

Roadmapping and Mentoring

Agile Artisans - Wed, 01/21/2015 - 02:00

A coaching model that I've found very effective is something I call roadmapping and mentoring. In a traditional coaching engagement, the coach comes alongside the team and works onsite for some period of time. This is a very effective way to work and teach, but also requires a substantial budget commitment. It also needs a dedicated block of time from the coach. Lining up client needs with coach?s availability is often challenging, and there?re usually problems that are discovered after the engagement is complete and the coach is at a different client site. These problems are often insurmountable for the small or medium software shop.

Roadmapping puts a coach back in reach for most teams. The coach comes onsite for only few days, and that drastically reduces the cost. I meet with both the teams and the leadership. What pain points triggered this invitation? We try to identify what the existing pain is, but we also look for pain that the team has come to accept as normal. What hidden pain poi

Categories: Companies

DevOps Evangelist Dominica DeGrandis Joins LeanKit

We’re excited that Dominica DeGrandis has joined LeanKit as our Director of Training and Coaching. Dominica is well known for her work with IT and Operations teams as a Kanban for DevOps trainer and coach. As a highly recognized international speaker, she’s often on the road, appearing at events focused on Lean, Kanban, Agile, and DevOps. […]

The post DevOps Evangelist Dominica DeGrandis Joins LeanKit appeared first on Blog | LeanKit.

Categories: Companies

Kick Off 2015 with New Features

Over the past several weeks, we’ve released many features including enhancements to the mobile apps, calendar view, and collaboration tools. Here’s a quick rundown so you know what to try the next time you’re in LeanKit. Using My LeanKit Mobile Apps — Offline Your new ideas and to-do items won’t get lost when you’re unable to connect to […]

The post Kick Off 2015 with New Features appeared first on Blog | LeanKit.

Categories: Companies

Backlog Selection By Cost of Delay

Scrum Expert - Tue, 01/20/2015 - 19:58
Managing the product backlog and prioritizing the user stories if one of the main responsibilities of the product owners in Scrum. In this blog post, Andy Carmichael explains how to assess the priority of product backlog items using the cost of delay. The cost of Delay is the cost to bear as a result of delay in investment. Andy Carmichael bases his analysis on David Anderson’s Kanban book that proposes four archetypes to categorize the costs of delay, plotting on a chart the impact (opportunity cost) against the time of release. ...
Categories: Communities

Integrating MediatR with Web API

Jimmy Bogard - Tue, 01/20/2015 - 19:25

One of the design goals I had in mind with MediatR was to limit the 3rd party dependencies (and work) needed to integrate MediatR. To do so, I only take a dependency on CommonServiceLocator. In MediatR, I need to resolve instances of request/notification handlers. Rather than build my own factory class that others would need to implement, I lean on CSL to define this interface:

public interface IServiceLocator : IServiceProvider
{
    object GetInstance(Type serviceType);
    object GetInstance(Type serviceType, string key);
    IEnumerable<object> GetAllInstances(Type serviceType);
    TService GetInstance<TService>();
    TService GetInstance<TService>(string key);
    IEnumerable<TService> GetAllInstances<TService>();
}

But that wasn’t quite enough. I also wanted to support child/nested containers, which meant I didn’t want a single instance of the IServiceLocator. Typically, when you want a component’s lifetime decided by a consumer, you depend on Func<Foo>. It turns out though that CSL already defines a delegate to provide a service locator, aptly named ServiceLocatorProvider:

public delegate IServiceLocator ServiceLocatorProvider();

In resolving handlers, I execute the delegate to get an instance of an IServiceLocatorProvider and off we go. I much prefer this approach than defining my own yet-another-factory-interface for people to implement. Just not worth it. As a consumer, you will need to supply this delegate to the mediator.

I’ll show an example using StructureMap. The first thing I do is add a NuGet dependency to the Web API IoC shim for StructureMap:

Install-Package StructureMap.WebApi2

This will also bring in the CommonServiceLocator dependency and some files to shim with Web API:

image

I have the basic building blocks for what I need in order to have a Web API project using StructureMap. The next piece is to configure the DefaultRegistry to include handlers in scanning:

public DefaultRegistry() {
    Scan(
        scan => {
            scan.TheCallingAssembly();
            scan.AssemblyContainingType<PingHandler>();
            scan.WithDefaultConventions();
			scan.With(new ControllerConvention());
            scan.AddAllTypesOf(typeof(IRequestHandler<,>));
            scan.AddAllTypesOf(typeof(IAsyncRequestHandler<,>));
            scan.AddAllTypesOf(typeof(INotificationHandler<>));
            scan.AddAllTypesOf(typeof(IAsyncNotificationHandler<>));
        });
    For<IMediator>().Use<Mediator>();
}

This is pretty much the same code you’d find in any of the samples in the MediatR project. The final piece is to hook up the dependency resolver delegate, ServiceLocatorProvider. Since most/all containers have implementations of the IServiceLocator, it’s really about finding the place where the underlying code creates one of these IServiceLocator implementations and supplies it to the infrastructure. In my case, there’s the Web API IDependencyResolver implementation:

public IDependencyScope BeginScope()
{
    IContainer child = this.Container.GetNestedContainer();
    return new StructureMapWebApiDependencyResolver(child);
}

I modify this to use the current nested container and attach the resolver to this:

public IDependencyScope BeginScope()
{
    var resolver = new StructureMapWebApiDependencyResolver(CurrentNestedContainer);

    ServiceLocatorProvider provider = () => resolver;

    CurrentNestedContainer.Configure(cfg => cfg.For<ServiceLocatorProvider>().Use(provider));
    
    return resolver;
}

This is also the location where I’ll attach per-request dependencies (NHibernate, EF etc.). Finally, I can use a mediator in a controller:

public class ValuesController : ApiController
{
    private readonly IMediator _mediator;

    public ValuesController(IMediator mediator)
    {
        _mediator = mediator;
    }

    // GET api/values
    public IEnumerable<string> Get()
    {
        var result = _mediator.Send(new Ping());

        return new string[] { result.Message };
    }

That’s pretty much it. How you need to configure the mediator in your application might be different, but the gist of the means is to configure the ServiceLocatorProvider delegate dependency to return the “thing that the framework uses for IServiceLocator”. What that is depends on your context, and unfortunately changes based on every framework out there.

In my example above, I’m preferring to configure the IServiceLocator instance to be the same instance as the IDependencyScope instance, so that any handler instantiated is from the same composition root/nested container as whatever instantiated my controller.

See, containers are easy, right?

(crickets)

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

News update 2015/01 – Scrum Coaching Retreat Cape Town

ScrumSense.com - Peter Hundermark - Tue, 01/20/2015 - 15:29

Scrum Coaching Retreat Cape TownYou may be considering attending the upcoming Scrum Coaching Retreat (SCR) to be held in Franschhoek, near Cape Town on 09-11 February 2015. And you may be wondering what the value will be to you. You may also need to find a convincing argument for your boss to sign off on the registration fee and, perhaps, travel costs from Jhb or elsewhere.

Well in this month’s blog post, Peter Hundermark shares his personal experiences of past Scrum Coaching Retreats in Colorado and London. Discover what he learnt and what to expect from South Africa’s inaugural event! Read more HERE.

CLICK FOR EVENT DETAILS Upcoming Courses Certified Scrum Master (CPT)
26-27 Jan 2015
Steenberg Hotel, Cape Town

 

Certified Scrum Master (JHB)
03-04 Feb 2015
FNB Conference & Learning Centre, Sandton

 

Certified Scrum Product Owner (CPT)
23-24 Feb 2015
Steenberg Hotel, Cape Town

 

Certified Scrum Master (JHB)
10-11 Mar 2015
FNB Conference & Learning Centre, Sandton

 

Course schedule and Book Online

The post News update 2015/01 – Scrum Coaching Retreat Cape Town appeared first on ScrumSense.

Categories: Blogs

Viktor Frankl’s Meaning Triangle for Organizations

Agile For All - Bob Hartman - Tue, 01/20/2015 - 15:15

Viktor_Frankl2Viktor Frankl was an incredible human being, having survived the Holocaust and establishing logotherapy, a type of psychotherapy. His book, Man’s Search for Meaning, details his development of his theory around meaning and suffering.

And he was a student of suffering as he and his fellow prisoners walked through horrifying conditions. What he discovered, though, was how some of his colleagues were able to not only survive but grow in the process.

His conclusion – that the most basic human motivation is the will to meaning, and as Nietzsche put it,

He who has a why to live for can bear almost any how.

Frankl outlines further what he calls the “Meaning Triangle” as a way of processing the growth that some would face in seemingly hopeless circumstance:

  1. Creativity – Giving something to the world through self-expression and using our talents in various ways.
  2. Experiencing – Receiving from the world through nature, culture, relationships, and interactions with others and with our environment.
  3. Change of Attitude – Even if we can’t change a situation or circumstance we can still choose our attitude toward a condition. This is often a self-transcending way of finding meaning through suffering.

viktor-frankl-meaning-triangleI have been personally inspired by Viktor Frankl’s story and his work as he has created some incredible points of connection for me as I have walked through difficult times.

His work in logotherapy has also provided many talking points for the variety of teams, organizations, and cultures that we engage with – as all teams and businesses are challenged with being responsible for their human capital (creativity) and managing it well, creating the right environment for their staff and teams to operate (experiencing), and finally providing the right tools and culture to assist in developing a positive attitude (or change of attitude) to do their best work.

How have you experienced the Meaning Triangle in your context and in your organization? What are the tools or the systems within your culture that help your team achieve greater results, individually and collectively?

Now, we wouldn’t always say (at least explicitly) that we’re “suffering” in our work daily, and obviously not to the extent of which Frankl has experienced, but we all know what it’s like to work in environments where it seems “meaning” and “purpose” are often dismissed for the tasks at hand or stepped over for the sake of surviving the “daily grind.”

What I love doing is to help organizations move back to their original purpose(s) and what made them such an exciting organization to work for and with – and help capture the reasons why they exist in the first place. This reminds the individuals and teams that there’s meaning behind the “suffering” and even greater opportunities to thrive.

The post Viktor Frankl’s Meaning Triangle for Organizations appeared first on Agile For All.

Categories: Blogs

Fantastic Team Building Activity!

Growing Agile - Tue, 01/20/2015 - 11:45

We talk a lot about the importance of creating teams in agile. People need to learn to work together towards an overall goal and share accountability rather than each person doing only their piece and not caring about the whole. It takes a long time for a new team to gel and really become a team, but there are team building activities that can help.

In December, I was lucky enough to discover a great team building activity available in Cape Town, London, Paris and Dubai! It’s called HintHunt. My team and I enjoyed it so much we went back in January to play their second room!

Team Code Monkeys cracks the Zen room at Hint Hunt.

Team Code Monkeys cracks the Zen room at Hint Hunt.

What is it?

  • Imagine a team of people (3 to 6)
  • With a strict timebox of 1 hour (let’s call it a sprint)
  • and a shared goal to achieve in that time (getting out of the room)

How do you do it?

  • You have to use problem solving skills
  • And communicate well between all the team members
  • You can even track where you are with a whiteboard

Does everyone succeed?

Actually no, that’s the part that makes it so much fun, it’s a real challenge. I don’t remember the exact stats but only about 40% of people have solved the first room, and about 10% have solved the new zen room.

Anyone else thinking this sounds exactly like Scrum?

As soon as I played I realised this is the ideal game for a Scrum team to play together. It builds teams to do exactly what they need to do to build great software, and it’s a great deal of fun. So if you live in one of the cities I’ve mentioned be sure to check it out.

Let us know if you beat our record of 1 min 59 sec remaining on the clock for the Zen room :)

Categories: Companies

The ‘Agile Playbook’

Agile Management Blog - VersionOne - Mon, 01/19/2015 - 20:51

Football players spend a lot of time studying their Playbooks. And Coaches spend a lot of time creating and updating them. These guys are serious. The stakes are high in the NFL; millions of people are watching. Their stated goal is the same each week; to win. That means they gotta work really well together and know what they’re doing.

AgilePlaybook

I think the game of American football is a great example to follow as an Agile team in the corporate world. We all need some help with remembering stuff, and getting it down so we can execute on game day. Even if we’ve done it many times before, it’s easy to get forget; there’s just so much to know and remember. This is hard stuff we’re doing, and it’s in constant flux. We often find ourselves wanting someplace to go for reference, clarification, advice, dare I say… ‘best practices.’

I’ve had several clients (both large and small) ask me for something they could use to document the way they ‘do Agile.’ If they’re new to the game, often they will look to a consultant or Agile Coach to guide them or help create this information.

Enter ‘The Agile Playbook.’

So what is an ‘Agile Playbook,’ anyway?

In short, it’s a helpful guide. It can come in many forms. For now, let’s stick with the football analogy. If you’ve watched an NFL game recently, you’ve probably seen the coach holding up a play sheet, as he decides what play to call. If you (or your kid) has an XBOX or PlayStation with Madden NFL, you know it has a Playbook feature built into it. Note: this could be an interesting feature opportunity for Agile Lifecycle Management (ALM) tool providers, huh? But I digress. So, as for the Playbook itself, I think of this as the larger, over-arching deliverable.

Transferring this idea of an NFL Playbook into the world of Agile software development is natural. I’ve heard it referred to by different folks in similar ways, like ‘Agile one-stop shopping’, or an ‘Agile Coach in a Box’, or ‘How we do Agile here at Company XYZ’. I personally like the term ‘Agile Playbook’ because it’s short, simple, descriptive, and I believe it drives home the team concept nicely.

Who wants an Agile Playbook?

Can you imagine an NFL team without an organized list of plays? So why would we think it’d be any different in our Agile organizations? I remember playing pickup football and we’d draw pictures in the dirt of what we wanted to do. That was fine for a pickup game, but even my nine-year-old son’s flag football team has a playbook. So the question of ‘Who wants it?’ is an appropriate one. If we think of Mike Cohn’s user story template (As a ___, I want to ___, so I can ___), this is the ‘As a’ piece. Who are we doing this for, anyway? Is it the PMO Director? The ScrumMasters? Product Owners? The Team? Program and Portfolio Management? Executives? The answer, in my six years of personal Agile consulting experience, is ‘all the above.’ If they don’t ask about this at some point, it’s usually because they haven’t thought about it yet.

Why do they want an Agile Playbook?

Hopefully, because it adds value. This is the ‘So I can’ part of the story. It’s a guide to help them get where they want to go. It’s something we can point to when someone asks, “How are we doing Agile in our organization?” It’s something we can go to for reference when nobody else is around. It can even be used as an onboarding tool.

The Agile Playbook also gets us thinking not only about how we work, but how we can improve our processes. Are we really being empirical? Give it a little love in your retrospectives. Perhaps there’s an opportunity to update the Playbook. Oh, and if by chance you don’t see any value in it, simply don’t do it.

Yes, it’s a document.

OK, I know what many of you must be thinking by now… The Agile Manifesto says ‘Working software over comprehensive documentation.’ Yes, an Agile Playbook is a document. And yes, it’s likely to be pretty comprehensive. But that’s a relative term; more specifics on this will follow in a bit. The Agile Manifesto doesn’t say documents are evil. In this case, I believe it’s a very helpful and necessary document to have available in order to get everyone on the same page, and to show auditors that our processes are documented (they like that kinda stuff, ya know). An Agile Playbook is a big deliverable. It takes a lot of time, effort and know-how to put something like this together.

When I did one for a client a couple years ago, we employed a full-time Tech Writer for about a month. That was a huge help. I had initially tried to do it on my own, in my spare time, but that didn’t work out too well. The folks in the Agile PMO, including myself, provided the content, primarily.

But I’ve seen other organizations go with almost nothing documented, just pulling in a coach or two and letting it roll. Maybe sharing a few slide decks on an internal page. No strong desire to document the why, when and how we do stuff. I wonder if that’s because they hadn’t thought about it, didn’t want it by design, or just didn’t have the bandwidth. Or maybe there were other reasons. Personally, I believe that not documenting something this important to the agile transformation of your organization is irresponsible.

And having it documented – but all over the place in different formats – can be chaotic. I don’t like to make people go hunt down stuff, let alone guess or assume anything.

My opinion is that this should be as close to one document (or series of web pages) as possible, not multiples; i.e., not nine Powerpoint slide decks, seven Excel spreadsheets, and 12 Word documents with a bunch of buried links to even more documents, slide decks and spreadsheets. Make it as simple as possible. It’s one place to go. One thing to print off (if you desire to have a hard copy) and carry with you for reference. One URL to save as a favorite.

It can help us realize gaps in the way we work.

What I learned early on is that the hard work of creating an Agile Playbook forces us to give a long, hard look at the way we’re working now, and how we want to work in the future. It’s cathartic. It helps us identify areas where we can improve our processes. It forces us to ask some difficult questions. And make some difficult decisions.

One way in which to identify areas of improvement around your process is to identify your value streams. This is a basic Lean principle. I’m sure we’ve all done something like this. How efficient are we in going from start to finish (request to deployment, concept to cash)? Our goal should be to optimize this. Look to reduce delays, inefficiencies, and improve our cycle time.

How do we document tools and technical practices?

Let’s not forget how our tools and technical practices play into this, as they’re an important factor in how we get work done. If your organization is using an Agile Lifecycle Management tool, the Agile Playbook might include best practices on how to use that as well – either melded throughout, or as a separate section.

Same goes for development tools that help us with…

– Continuous integration – Jenkins, Hudson
– Defect Management – Bugzilla, JIRA, HP Quality Center
– Integrated Development Environment – Eclipse, Visual Studio
– Test Management – HP Quality Center
– Source Code Management – Git, Subversion
Agile Portfolio and Project Management – VersionOne, et al.

This can be a lot of information, so when documenting for the Agile Playbook, this is an area where I make heavy use of links to information beyond the basics of each of the tools we use.

It should be comprehensive, yet brief.

If you can’t fit the Agile Playbook into your front pocket comfortably, it’s probably too big. When I say brief, I mean about under 50 pages for a large organization. Any more than that, I think folks begin to feel overwhelmed and push it away. Any less, and it’s hard to be comprehensive. There’s no science behind that decision, but if I apply my own average attention span to the matter, this sounds about right. I think much of this also depends on the format you use: Microsoft Word, Powerpoint, HTML, etc. Again, where appropriate, I like to make liberal use of links to other documents/sources to help minimize the length. I recommend placing it on a well-known organizational site such as Wiki, Sharepoint, etc. Provide a highly visible and pronounced link from your internal company home page, and give the option of printing out a hard copy. In fact, I like to have several hard copies available in the Agile PMO to hand out to folks who want one. You’d be surprised how quickly they go. I’ve found that a nice ringed binder works best. That way, if there are changes, you can swap out a page or two. That said…

Did you know…

Most NFL teams now use tablets (iPad or Surface) almost exclusively for their Team Playbooks?

broncos-120423If you’ve watched ‘Hard Knocks’ on HBO, you already know that the phrase “Turn in Your iPads” has started replacing “Turn in Your Playbooks” when players are cut from an NFL team. Those teams have discovered that the technology goes far beyond the old playbook capabilities. There’s a product called ‘PlayerLync,’ which is at the forefront of this movement. It has revolutionized the way teams push out film and significantly altered the way they communicate. Beyond saving printing costs, digital playbooks are improving the effective, real-time communication by allowing coaches and quarterbacks to add and share plays with the click of a button. Every time new data, film or information is added, a banner alert pops up (like a text message), signaling players to view the updates.

Oh, and PlayerLync isn’t just for professional sports teams. Here’s a short clip on how Chipotle and others are using it to push content to their teams:

http://www.playerlync.com/who-wins-with-playerlync/corporate-communications/

Uniqueness and commonalities

I’ve helped put together a number of these Agile Playbooks for different clients now, and each was both unique. But there are many commonalities, like the general Agile principles and practices. At the end of the day, folks want to know what to do, who does it, when to do it, and why. All these things can be exclusive to the organization or industry. The extent to which Scrum, Lean, and XP practices are applied also varies from company to company.

Fear

The fear seems to be centered around teams in an organization that are using both the framework and the tools differently. It could be that we’re not all using the Agile Lifecycle Management tool in the same way. How in the world can we expect to have rolled up views into the different management levels (Portfolio, Program, and Project) without a common agile project management tool? This opens the door to confusion on many levels, especially when we start talking about agile metrics/reports. But it’s not just the management level that has a problem if we’re not all on the same page. The individual team members also experience fear… fear of doing the wrong thing, or doing it incorrectly, getting called to the carpet or, worse yet, being publicly shamed, written up, or fired. The idea is that if we’re all on the same page, and everyone knows what’s expected, this fear diminishes greatly. Life gets better for everyone.

Start with an outline…

Finally, you were probably wondering when I was going to get here. By the way, each organization’s Agile Playbook is their own. I cannot share the exact Playbooks that I’ve put together with clients, as that information is proprietary. But I can share with you a more generic outline of what an Agile Playbook might look like:

About the Agile Playbook
What is Agile and Scrum?
Implementing Agile and Scrum at Company XYZ
Essentials of Agile and Scrum at Company XYZ (How ‘We’ Do It)
Agile Planning
Agile Execution
Agile Cultivation
Agile Tools
Agile Reporting/Agile Metrics
Staying Compliant with Agile
Company XYZ Communities of Practice (COP)
Conclusion
Bibliography
References

Do you have a Playbook for how you ‘do Agile’ in your organization? If so, what does it look like? If not, why?

Categories: Companies

Discovering Your Leadership Posted

Johanna Rothman - Mon, 01/19/2015 - 20:01

I published a new Pragmatic Manager this past weekend. It’s called Discovering Your Leadership.

It has a pointer to the Influential Agile Leader event that Gil Broza and I are leading in San Francisco and then in London. You can still get early bird pricing, until Feb 15. Don’t miss this opportunity—we’re only leading it twice this year.

Categories: Blogs

Using User Stories for Non-Functional Requirements

Scrum Expert - Mon, 01/19/2015 - 18:50
Non-functional requirements relate to qualities of the system that cut across user facing features, such as security, reliability, and performance. How does an Agile team take care of these non-functional requirements? This presentation discusses if user stories are of any use in this situation and how Scrum teams can applying Agile techniques to solve these concerns.Video producer: http://www.devopsdays.org/ Further reading: Non-Functional Requirements: Do User Stories Really Help?
Categories: Communities

Agile Adria Conference, Tuheljske Toplice, Croatia, April 13-14 2015

Scrum Expert - Mon, 01/19/2015 - 16:16
Agile Adria Conference is a three-day conference that takes place in Croatia and focuses on Agile and Scrum. Its goal is as a regional event is to be the meeting point for Agilists from Croatia, Slovenia, Italy, Austria, Hungary, Serbia and Bosnia-Herzegovina. Speakers are experts coming from both Europe and the USA. Among the expert for the Agile Adria conference, you will find known authors like Marry Poppendick and Sephen Parry. In the agenda of the Agile Adria conference,  you can find topics like “How to improve estimates for software: The #NoEstimates ...
Categories: Communities

VAST – Virtuous Cycle for Connection

Agilitrix - Michael Sahota - Mon, 01/19/2015 - 15:57

It’s all about how we show up. If we show up in a way that invites people to connect, to trust, to feel safer than usual, they probably will. And astonishing results will follow. Olaf and I have a vast experience of limiting our results because we didn’t dare to show up, speak up, stand up. We’ve been not daring, not trying, not challenging, most of our lives—like most people! We’ve learned the hard way how to show up in a way that enables connection, and impact.

We use the VAST cycle to increase connection to grow engagement in the workplace. We know safety and trust are important, but that is not the whole story. We need whole humans, intensely connected, to unleash the co-creation of astonishing results.

Joint post with Olaf Lewitz.

VAST Cycle Virtuous Cycle for Connection

Virtuous Cycle for Connection

VAST =
Vulnerability
Authentic Connection
Safety
Trust

How to use VAST for Yourself

We use VAST as a way to navigate relationships. It works in personal and professional contexts.

Use VAST for introspection: In relation to another, we may ask ourselves:

  • How trusting am I?
  • How safe do I feel?
  • How connected do I feel?
  • How vulnerable am I choosing to be?
  • Am I acting authentically?

With this new awareness, the model suggests a variety of moves:

  • I can choose to be vulnerable and share how I feel. How I am feeling unsafe. How I am not trusting.
  • I can choose to trust the other person and see how my behaviour shifts.
  • I can state what I want. “I want to restart this conversation. I want to focus on how we can support each other. I want to focus on the goal.”
  • I can ask for help.

In our experience, the most powerful move is vulnerability. Owning our experience and how we feel and then sharing it really kicks off the cycle. That’s what we mean by showing up.

I have a short video explanation of VAST in my People over Process talk.

VAST for Organizations

We use VAST to build awareness and choice for organizations. It is especially useful when contrasting with organizational debt (fear, mistrust) as a way of being.

A team, group, or organization may choose VAST as a future way of being. The cycle helps guide behaviour and create ideas for experiments.

We can use it in retrospectives, to collect narratives that demonstrate the behaviour we want. Acknowledge when someone was daring, inspiring us to move forward.

Run a Temenos lab to experience the cycle for yourself or with your team.

Origins of VAST

The VAST cycle is the result of a sense-making journey between Olaf and I over the past years. We have been learning and studying its elements to help ourselves and our clients grow. We didn’t go out to invent something, it just emerged – it’s a discovery. We then noticed how well it explains many beautiful personal and professional growth experiences with ourselves and our clients.

The term “VAST” was created by Anton Gillis-Adelman – who is an expert in turning a jumble of letters into words.

Related Work

The post VAST – Virtuous Cycle for Connection appeared first on Catalyst - Agile & Culture.

Related posts:

  1. Organizational Debt Cycle Many consider the modern workplace inhumane and uninhabitable. People are...
  2. People over Process – Win with People Success comes from Valuing People When we simplify the Agile...
  3. WholeHearted Manifesto: We Value People The WholeHearted Manifesto consists on one value statement: We Value...

YARPP powered by AdBistroPowered by

Categories: Blogs

Try is free in the Future

Xebia Blog - Mon, 01/19/2015 - 10:40

Lately I have seen a few developers consistently use a Try inside of a Future in order to make error handling easier. Here I will investigate if this has any merits or whether a Future on it’s own offers enough error handle.

If you look at the following code there is nothing that a Future can’t supply but a Try can:

import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.{Await, Future, Awaitable}
import scala.concurrent.duration._
import scala.util.{Try, Success, Failure}

object Main extends App {

  // Happy Future
  val happyFuture = Future {
    42
  }

  // Bleak future
  val bleakFuture = Future {
    throw new Exception("Mass extinction!")
  }

  // We would want to wrap the result into a hypothetical http response
  case class Response(code: Int, body: String)

  // This is the handler we will use
  def handle[T](future: Future[T]): Future[Response] = {
    future.map {
      case answer: Int => Response(200, answer.toString)
    } recover {
      case t: Throwable => Response(500, "Uh oh!")
    }
  }

  {
    val result = Await.result(handle(happyFuture), 1 second)
    println(result)
  }

  {
    val result = Await.result(handle(bleakFuture), 1 second)
    println(result)
  }
}

After giving it some thought the only situation where I could imagine Try being useful in conjunction with Future is when awaiting a Future but not wanting to deal with error situations yet. The times I would be awaiting a future are very few in practice though. But when needed something like this migth do:

object TryAwait {
  def result[T](awaitable: Awaitable[T], atMost: Duration): Try[T] = {
    Try {
      Await.result(awaitable, atMost)
    }
  }
}

If you do feel that using Trys inside of Futures adds value to your codebase please let me know.

Categories: Companies

5 Steps for Creating High-Performance Teams eBook

Notes from a Tool User - Mark Levison - Mon, 01/19/2015 - 09:44

Certified Scrum Trainer Mark Levison has been around the block, more than a few times, and he was getting frustrated by what he saw happening in Scrum. When Mark is invited into businesses and industries to talk with Scrum teams, it’s typically with the request to help them do Scrum better so they can be more productive.

But practicing the mechanics of Scrum is not the answer to high performance. Yes, you’ll get some benefits, but not the most important ones. You can focus on the ceremonies – the daily stand-ups, the sprint planning, the retrospectives – and still not get the performance you’re expecting, or seeking.

So… why? What’s the secret? What’s the magic formula?

That’s what Mark wanted to know, which led him to study the elements that are found in high-performing teams. And what he discovered was actual neuroscience and behavioural psychology that makes the social aspects of team building surprisingly clear in their importance.

Now Mark has taken what he learned in those discoveries, and formed them into five proven and practical Agile steps that can put a team on the path to high-performance success. And here’s sharing them with you now, here:

  1. A free eBook of the “5 Steps Towards Creating High-Performance Teams“. This outlines the key elements, the magic and neuroscience behind them, and how to implement them with your team.
  2. The High-Performance Teams Game. Fun downloadable resources to help teams see the effects of choices/tradeoffs on productivity and team cohesion.
  3. This handy – and, dare we say, snazzy – infographic to summarize, focus, and remind.

Agile Pain Relief Five Steps Towards Creating High Performance Teams Infographic

 

Building a high-performing team doesn’t have to be complicated, nor is it luck of the draw. Surprisingly, most of it is simply common sense and awareness of human behaviour and relationships. That’s it.
Categories: Blogs

Are You an Agile Company?” – Job Interview Guidelines for Generation Y

Scrum 4 You - Mon, 01/19/2015 - 08:40

In recent months, more and more friends graduating from university or looking to change jobs have asked me whether I could recommend any agile companies to them. This enquiry usually goes hand in hand with the question of how one can actually tell whether a company is agile or not. As a member of the infamous Generation Y, I completely understand that companies, which support and live by the agile values are far more interesting employers. After all, openness, respect, focus, commitment and courage along with agile leadership practices such as Management 3.0 fill my need for self-organization and carrying out value-driven work. However, detecting whether a company can truly be called agile is not so easy. Firstly, many companies spend valuable money on marketing campaigns in order to present themselves as riding with the current agile wave. Secondly, a certain amount of insight into a company is necessary before one is able to pinpoint an organization’s core values. So apart from the usual googling, consulting websites like kununu, or asking around, I suggest that one actually uses the opportunity of the job interview itself to get more insight.

Inspired by the discussion from an Open Space session on the topic of „How do we know whether an organisation is agile?!” that I hosted at last year’s Agile Coach Camp in Kandersteg (a fantastic un-conference that you should definitely participate in this year) as well as random conversations with friends and colleagues, I have put together an unprioritized set of job interview questions. Of course, this list is not complete and these questions are in addition to the usual ones that you should ask at a job interview …

  • What does the company’s organizational structure look like? (i.e. hierarchies, career paths, departmental silos etc.)
  • How does the company handle staff reviews and performance appraisals?
  • How will my performance be measured?
  • How would you describe the company’s feedback culture? Can you give me any examples?
  • What aspects do you appreciate most about your current employees / co-workers?
  • What are the working conditions like? (i.e. open office, flexible work hours, slack time etc.)
  • How would you describe the communication between the various levels of management and their employees?
  • How much outsourcing and offshoring is being done?

Before you begin with your questions, it might be an idea to start off by explaining how important the work environment and culture are to you for achieving your highest potential. For this reason, you need to ask a few strange questions. And then you ask whatever you wish to ask. However, don’t forget to generally have a look at the company’s hiring practices, as this says a lot about its culture already. That means: Who is interviewing you (team member, management, HR)? What kind of questions are they asking you? What is the atmosphere of the interview like? What do the offices look like?

What do you think – would the answers to these questions help you with your job decision? Can you think of some more questions? What else would you recommend to figure out whether your future employer shares the same values?

Categories: Blogs

Python/NLTK: Finding the most common phrases in How I Met Your Mother

Mark Needham - Mon, 01/19/2015 - 02:24

Following on from last week’s blog post where I found the most popular words in How I met your mother transcripts, in this post we’ll have a look at how we can pull out sentences and then phrases from our corpus.

The first thing I did was tweak the scraping script to pull out the sentences spoken by characters in the transcripts.

Each dialogue is separated by two line breaks so we use that as our separator. I also manually skimmed through the transcripts and found out which tags we need to strip out. I ended up with the following:

import csv
import nltk
import re
import bs4
 
from bs4 import BeautifulSoup, NavigableString
from soupselect import select
from nltk.corpus import stopwords
from collections import Counter
from nltk.tokenize import word_tokenize
 
episodes_dict = {}
 
def strip_tags(soup, invalid_tags):
    for tag in invalid_tags:
        for match in soup.findAll(tag):
            match.replaceWithChildren()
    return soup
 
def extract_sentences(html):
    clean = []
    brs_in_a_row = 0
    temp = ""
    for item in raw_text.contents:
        if item.name == "br":
            brs_in_a_row = brs_in_a_row + 1
        else:
            temp = temp + item
        if brs_in_a_row == 2:
            clean.append(temp)
            temp = ""
            brs_in_a_row = 0
    return clean
 
speakers = []
with open('data/import/episodes.csv', 'r') as episodes_file, \
     open("data/import/sentences.csv", 'w') as sentences_file:
    reader = csv.reader(episodes_file, delimiter=',')
    reader.next()
 
    writer = csv.writer(sentences_file, delimiter=',')
    writer.writerow(["SentenceId", "EpisodeId", "Season", "Episode", "Sentence"])
    sentence_id = 1
 
    for row in reader:
        transcript = open("data/transcripts/S%s-Ep%s" %(row[3], row[1])).read()
        soup = BeautifulSoup(transcript)
        rows = select(soup, "table.tablebg tr td.post-body div.postbody")
 
        raw_text = rows[0]
        [ad.extract() for ad in select(raw_text, "div.ads-topic")]
        [ad.extract() for ad in select(raw_text, "div.t-foot-links")]
        [ad.extract() for ad in select(raw_text, "hr")]
 
        for tag in ['strong', 'em', "a"]:
            for match in raw_text.findAll(tag):
                match.replace_with_children()
        print row
        for sentence in [
                item.encode("utf-8").strip()
                for item in extract_sentences(raw_text.contents)
            ]:
            writer.writerow([sentence_id, row[0], row[3], row[1], sentence])
            sentence_id = sentence_id + 1

Here’s a preview of the sentences CSV file:

$ head -n 10 data/import/sentences.csv
SentenceId,EpisodeId,Season,Episode,Sentence
1,1,1,1,Pilot
2,1,1,1,Scene One
3,1,1,1,[Title: The Year 2030]
4,1,1,1,"Narrator: Kids, I'm going to tell you an incredible story. The story of how I met your mother"
5,1,1,1,Son: Are we being punished for something?
6,1,1,1,Narrator: No
7,1,1,1,"Daughter: Yeah, is this going to take a while?"
8,1,1,1,"Narrator: Yes. (Kids are annoyed) Twenty-five years ago, before I was dad, I had this whole other life."
9,1,1,1,"(Music Plays, Title ""How I Met Your Mother"" appears)"

The next step is to iterate through each of those sentences and create some n-grams to capture the common phrases in the transcripts.

In the fields of computational linguistics and probability, an n-gram is a contiguous sequence of n items from a given sequence of text or speech.

Python’s nltk library has a function that makes this easy e.g.

>>> import nltk
>>> tokens = nltk.word_tokenize("I want to be in an n gram")
>>> tokens
['I', 'want', 'to', 'be', 'in', 'an', 'n', 'gram']
>>> nltk.util.ngrams(tokens, 2)
[('I', 'want'), ('want', 'to'), ('to', 'be'), ('be', 'in'), ('in', 'an'), ('an', 'n'), ('n', 'gram')]
>>> nltk.util.ngrams(tokens, 3)
[('I', 'want', 'to'), ('want', 'to', 'be'), ('to', 'be', 'in'), ('be', 'in', 'an'), ('in', 'an', 'n'), ('an', 'n', 'gram')]

If we do a similar thing of HIMYM transcripts while stripping out the speaker’s name – lines are mostly in the form “Speaker:Sentence” – we end up with the following top phrases:

import nltk
import csv
import string
import re
 
from collections import Counter
 
non_speaker = re.compile('[A-Za-z]+: (.*)')
 
def extract_phrases(text, phrase_counter, length):
    for sent in nltk.sent_tokenize(text):
        strip_speaker = non_speaker.match(sent)
        if strip_speaker is not None:
            sent = strip_speaker.group(1)
        words = nltk.word_tokenize(sent)
        for phrase in nltk.util.ngrams(words, length):
            phrase_counter[bphrase] += 1
 
phrase_counter = Counter()
 
with open("data/import/sentences.csv", "r") as sentencesfile:
    reader = csv.reader(sentencesfile, delimiter=",")
    reader.next()
    for sentence in reader:
        extract_phrases(sentence[4], phrase_counter, 3)
 
most_common_phrases = phrase_counter.most_common(50)
for k,v in most_common_phrases:
    print '{0: <5}'.format(v), k

And if we run that:

$ python extract_phrases.py
1123  (',', 'I', "'m")
1099  ('I', 'do', "n't")
1005  (',', 'it', "'s")
535   ('I', 'ca', "n't")
523   ('I', "'m", 'not')
507   ('I', 'mean', ',')
507   (',', 'you', "'re")
459   (',', 'that', "'s")
458   ('2030', ')', ':')
454   ('(', '2030', ')')
453   ('Ted', '(', '2030')
449   ('I', "'m", 'sorry')
...
247   ('I', 'have', 'to')
247   ('No', ',', 'I')
246   ("'s", 'gon', 'na')
241   (',', 'I', "'ll")
229   ('I', "'m", 'going')
226   ('do', "n't", 'want')
226   ('It', "'s", 'not')

I noticed that quite a few of the phrases had punctuation in so my next step was to get rid of any of the phrases that had any punctuation in. I updated extract_phrases like so:

def extract_phrases(text, phrase_counter, length):
    for sent in nltk.sent_tokenize(text):
        strip_speaker = non_speaker.match(sent)
        if strip_speaker is not None:
            sent = strip_speaker.group(1)
        words = nltk.word_tokenize(sent)
        for phrase in nltk.util.ngrams(words, length):
            if all(word not in string.punctuation for word in phrase):
                phrase_counter[phrase] += 1

Let’s run it again:

$ python extract_phrases.py
1099  ('I', 'do', "n't")
535   ('I', 'ca', "n't")
523   ('I', "'m", 'not')
449   ('I', "'m", 'sorry')
414   ('do', "n't", 'know')
383   ('Ted', 'from', '2030')
338   ("'m", 'gon', 'na')
334   ('I', "'m", 'gon')
300   ('gon', 'na', 'be')
279   ('END', 'OF', 'FLASHBACK')
267   ("'re", 'gon', 'na')
...
155   ('It', "'s", 'just')
151   ('at', 'the', 'bar')
150   ('a', 'lot', 'of')
147   ("'re", 'going', 'to')
144   ('I', 'have', 'a')
142   ('I', "'m", 'so')
138   ('do', "n't", 'have')
137   ('I', 'think', 'I')
136   ('not', 'gon', 'na')
136   ('I', 'can', 'not')
135   ('and', 'I', "'m")

Next I wanted to display each phrase as a string rather than a tuple which was more difficult than I expected. I ended up with the following function which almost does the job:

def untokenize(ngram):
    tokens = list(ngram)
    return "".join([" "+i if not i.startswith("'") and \
                             i not in string.punctuation and \
                             i != "n't"
                          else i for i in tokens]).strip()

I updated extract_phrases to use that function:

def extract_phrases(text, phrase_counter, length):
    for sent in nltk.sent_tokenize(text):
        strip_speaker = non_speaker.match(sent)
        if strip_speaker is not None:
            sent = strip_speaker.group(1)
        words = nltk.word_tokenize(sent)
        for phrase in nltk.util.ngrams(words, length):
            if all(word not in string.punctuation for word in phrase):
                phrase_counter[untokenize(phrase)] += 1

Let’s go again:

$ python extract_phrases.py
1099  I don't
535   I can't
523   I'm not
449   I'm sorry
414   don't know
383   Ted from 2030
338   'm gon na
334   I'm gon
300   gon na be
279   END OF FLASHBACK
...
151   at the bar
150   a lot of
147   're going to
144   I have a
142   I'm so
138   don't have
137   I think I
136   not gon na
136   I can not
135   and I'm

These were some of the interesting things that stood out for me and deserve further digging into:

  • A lot of the most popular phrases begin with ‘I’ – it would be interesting to filter those sentences to find the general sentiment.
  • The ‘untokenize’ function struggles to reconstruct the slang phrase ‘gonna’ into a single word.
  • ‘Ted from 2030′ is actually a speaker which doesn’t follow the expected regex pattern and so wasn’t filtered out.
  • ‘END OF FLASHBACK’ shows quite high up and pulling out those flashbacks would probably be an interesting feature to extract to see which episodes reference each other.
  • ‘Marshall and Lily’ and ‘Lily and Marshall’ show up on the list – it would be interesting to explore the frequency of pairs of other characters.

The code is all on github if you want to play with it.

Categories: Blogs

Meteor

Xebia Blog - Sun, 01/18/2015 - 13:11

Did you ever use AngularJS as a frontend framework? Then you should definitely give Meteor a try! Where AngularJS is powerful just as a client framework, meteor is great as a full stack framework. That means you just write your code in one language as if there is no back- and frontend at all. In fact, you get an Android and IOS client for free. Meteor is so incredibly simple that you are productive from the beginning.

Where meteor kicks angular

One of the killing features of meteor is that you'll have a shared code base for frontend and backend. In the next code snippet, you'll see a file shared by backend and frontend:

// Collection shared and synchronized accross client, server and database
Todos = new Mongo.Collection('todos');

// Shared validation logic
validateTodo = function (todo) {
  var errors = {};
  if (!todo.title)
    todo.title = "Please fill in a title";
  return errors;
}

Can you imagine how neat the code above is?

Scan 04 Jan 2015 18.48-page4

With one codebase, you get the full stack!

  1. As in the backend file and in the frontend file one can access and query over the Todos collection. Meteor is responsible for syncing the todos. Even when another user adds an item, it will be visible to your client directly. Meteor accomplishes this by a client-side Mongo implementation (MiniMongo).
  2. One can write validation rules once! And they are executed both on the front-end and on the back-end. So you can give my user quick feedback about invalid input, but you can also guarantee that no invalid data is processed by the backend (when someone bypasses the client). And this is all without duplicated code.

Another killer feature of meteor is that it works out of the box, and it's easy to understand. Angular can be a bit overwhelming; you have to learn concepts like directives, services, factories, filters, isolated scopes, transclusion. For some initial scaffolding, you need to know grunt, yeoman, etcetera. With meteor every developer can create, run and deploy a full-stack application within minutes. After installing meteor you can run your app within seconds.

$ curl https://install.meteor.com | /bin/sh
$ meteor create dummyapp
$ cd dummyapp
$ meteor
$ meteor deploy dummyapp.meteor.com
Screen Shot 2015-01-04 at 19.49.08

Meteor dummy application

Another nice aspect of meteor is that it uses DDP, the Distributed Data Protocol. The team invented the protocol and they are heavily promoting it as "REST for websockets". It is a simple, pragmatic approach allowing it to be used to deliver live updates as data changes in the backend. Remember that this works all out of the box. This talk walks you through the concepts of it. But the result is that if you change data on a client it will be updated immediately on the other client.

And there is so much more, like...

  1. Latency Compensation. On the client, Meteor prefetches data and simulates models to make it look like server method calls return instantly.
  2. Meteor is open source and integrates with existing open source tools and frameworks.
  3. Services (like an official package server and a build farm).
  4. Command line tools
  5. Hot deploys
Where meteor falls short

Yes, meteor is not the answer to all your problems. The reason, I'll still choose angular above meteor for my professional work, is because the view framework of angular rocks. It makes it easy to structure your client code into testable units and connect them via dependency injection. With angular you can separate your HTML from your javascript. With meteor your javascript contains HTML elements, (because their UI-library is based on handlebars. That makes testing harder and large projects will become unstructured very quickly.

Another flaw emerges if your project already has a backend. When you choose meteor, you choose their full stack. That means: Mongo as database and Node.js as backend. Despite you are able to create powerful applications, Meteor doesn't allow you (easily) to change this stack.

Under the hood

Meteor consists out of several subprojects. In fact, it is a library of libraries. In fact, it is a stack; a standard set of core packages that are designed to work well together:

Components used by meteor

  1. To make meteor reactive they've included the components blaze and tracker. The blaze component is heavily based on handlebars.
  2. The DDP component is a new protocol, described by meteor, for modern client-server communication.
  3. Livequery and full stack database take all the pain of data synchronization between the database, backend and frontend away! You don't have to think about in anymore.
  4. The Isobuild package is a unified build system for browser, server and mobile.
Conclusion

If you want to create a website or a mobile app with a backend in no time, with getting lots of functionality out of the box, meteor is a very interesting tool. If you want to have more control or connect to an existing backend, then meteor is probably less suitable.

You can watch this presentation I recently gave, to go along with the article.

Categories: Companies

Knowledge Sharing


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