Skip to content

Feed aggregator

Customer-Centric to the Core

At LeanKit, Lean isn’t just the product we sell. It’s in our name because we passionately believed...

The post Customer-Centric to the Core appeared first on Blog | LeanKit.

Categories: Companies

3 years later: SEI’s CIO looks back at their SAFe journey

Agile Product Owner - Mon, 06/13/2016 - 03:07

We always like to hear about early wins from new adopters of the Framework, but of course the real test of any method lies in how well it serves an organization over time. SEI—a leading global provider of wealth management solutions—launched their first ART in early 2014, and saw some impressive results:

  • 20%-25% increase in client satisfaction
  • Reduced code branching from 5 – 7 on average to a single code branch
  • Delivered higher value business results in a shorter delivery cycle

Now, three years later, SEI’s CIO, Robert F. Crudup, looks back at their SAFe journey in a CIOReview.com article, Transformation: Moving a Large Organization to Agile Development. He covers the full spectrum of challenges and wins. Their fast pivot to SAFe required 1,350 people to develop new skills, habits, and mindsets as they set about building a complex global securities accounting and trading system for multiple business segments.

Three years into this effort our SAFe transformation has taken strong root, leading to high quality, predictable software delivery and architectural runways.”
—Robert F. Crudup, SEI Investments Executive Vice President & CIO

This story proves (again) that SAFe is highly sustainable over time, and for those business leaders who recognize the importance of giving the culture time to evolve and change, there are significant long-term rewards.

Read the CIOReview article here.

Read the original case study here.

Many thanks to SEI’s Robert Crudup, SEI Investments EVP & CIO, for your leadership and sharing your transformation experience. Also, to Mona Roccia, Program Lead at SEI, for your important work in this SAFe adoption.

Stay SAFe!
–Dean

Categories: Blogs

Workshops in Kladno on Valuable Agile Retrospectives

Ben Linders - Sun, 06/12/2016 - 12:18

AguarraI will give two workshops in Kladno (near Prague) on making agile retrospectives valuable. In these workshops you’ll learn the why, what and how of agile retrospectives and practice exercises to develop your facilitation skills. Subscribe now to attend the workshop on November 1 or December 1 in Kladno, Czech Republic.

These workshops are done in collaboration with Aguarra, the competence center for agile techniques and technology innovations in Czech Republic, Slovakia and Hungary. Aguarra serves as a platform for experts, who work on research and implementation of agile techniques.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Attendant of this workshop will receive a free copy of the book Getting Value out of Agile Retrospectives in English or a copy of a translated edition.

The workshop on Valuable Agile Retrospectives can be combined with the workshop on Getting More out of Agile and Lean that I’m giving on on November 2 or December 2. These two days of workshops on Retrospectives and Agile and Lean practices help you to boost the performance of your teams, enabling them to deliver more value to their customers and stakeholders.

Regular price is 480 EUR / 576 EUR. Price when ordering until 01. 09. 2016 : 440 EUR / 528 EUR.

Categories: Blogs

Links for 2016-06-11 [del.icio.us]

Zachariah Young - Sun, 06/12/2016 - 09:00
Categories: Blogs

Its Dangerous To Go Alone

Derick Bailey - new ThoughtStream - Fri, 06/10/2016 - 22:46

Imagine a scene from the 1980’s. I’m in my basement with an 8-bit Nintendo Entertainment System and the class game of Zelda.

As I start the game, there’s a single black tile on the map. I walk into it to find an old man in the mountain, telling me that it’s dangerous to go alone.

What he says next, though, is something I still reflect on to this day. It’s an aspect of my life and my career that has become more and more important, as time moves on.

The idea that you *can* do everything on your own … it’s just not reasonable.

You need a support network, as we all do.

Categories: Blogs

One Week Remaining for Super-Early-Bird Registration for Product Owner and Writing Workshops

Johanna Rothman - Fri, 06/10/2016 - 18:55

I have two online workshops starting in late August:

If you have been reading the estimations posts and are wondering, “How do I help my project deliver something every day or more often,” you should register for the workshop. We’ll discuss what your role is, how to plan for the future and the present, how to decide what features to do when, how to know when a feature is done, and tips and traps. See Practical Product Owner Workshop: Deliver What Your Customers Need for more details.

If you like the way I write (regardless of whether you agree with me), and you need to write more for your job or to help your business, take my Non-Fiction Writing Workshop: Write Non-Fiction to Enhance Your Business and Reputation. That workshop is about building a writing habit, learning the separate parts of pre-writing, writing, editing, and publishing. We’ll address your specific writing challenges, concerns, and fears. I’m the only one who will read your work, so no worries about other people seeing your writing.

Super-early-bird registration for both workshops ends June 17, 2016. I hope you decide to join us.

Categories: Blogs

How Smart is Your City Transportation?

J.D. Meier's Blog - Fri, 06/10/2016 - 18:08

How easy is it to get around in your city from point A to point B?

Here’s an interesting article that rounds up some of the latest ideas:

Getting Around in European capitals: How smart is your city?

I really like this—talk about impact:

Autolib’ has taken thousands of cars off the roads, brought down driving costs by 90% and is reducing pollution by millions of metric tons per year.

Dense city + mass transit creates opportunities.

According to the article, here are what some cities are doing:

  1. In London, Transport of London implemented a contactless payment system, so users can just “touch in and out” to pay. When you’re dealing with a billion commuters a year, that’s a big deal.   Using Internet-of-Things, developers can use the sensors across London’s transport system, along with meaningful data in the Cloud, to build better transport apps that address technical incidents and protect passengers in new ways.
  2. In Paris, the Internet-of-Things made it possible to create Autolib, an electronic car-sharing solution. The fleet of electronic cars is managed centrally in the Cloud, allowing users to rent cars from kiosks and easily find charging stations. And users can easily find parking, too, with GPS-enabled parking.
  3. In Barcelona, they are using Internet-of-Things to improve Bicing, their bicycle sharing program. They can use sensors to monitor bicycle usage and detect issues between supply and demand. They can use that insight to distribute bikes better so that the bikes can be used in a more sustainable way. It’s smart logistics for bicycles in action.
  4. In Helsinki, they are using Internet-of-Things to get more value out of their 400 buses. By measuring acceleration, speed, engine temperature, fuel consumption, brake performance, and GPS location, they reduce fuel consumption, improve driver performance, and provide safer bus rides.

I also like how the article framed the challenge right up front by painting the scene of a common scenario where you have to stitch together various modes of transport to reach your destination:

“You just need to take Bus 2 for three stops,
then change to Bus 8 towards the City station,
walk for 10 minutes towards the docks,
then take Line 5 on the metro for 5 stops.
Then call a taxi.”

You can imagine all the opportunities to reimagine how people get around, and how inclusive the design can be (whether that means helping blind people safely find their next stop, or helping somebody from out of town, navigate their way around.)

Depending on how big the city is and how far out the city is spread, there is still room for Uber and Lyft to help stitch the end-to-end mass transit journey together.

And I wonder how long before Amazon’s Now drivers, go from local residents that fulfill orders, to become another ride share option (do Uber drivers become Amazon Now or do Amazon Now become Uber drivers?).

Categories: Blogs

Targetprocess v.3.8.9: Minor bug fixing

TargetProcess - Edge of Chaos Blog - Fri, 06/10/2016 - 16:40
Fixed Bugs:
  • Improved navigation for details view
  • Fixed comet reconnect functionality
  • Fixed an inability to convert a User Story when it has tasks that are related to each other
  • Fixed Custom Field name display in custom card units
  • Fixed a not working custom rule 'Assign a Task to the Person who started it'
  • Fixed annoying jumping of selected elements in relations pop-up
  • Fixed Effort display for custom card units
Categories: Companies

Links for 2016-06-09 [del.icio.us]

Zachariah Young - Fri, 06/10/2016 - 09:00
Categories: Blogs

Article Review: Craig Larman – Less Agile or LeSS Agile?

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

Certified Less Practitioner Badge

Craig Larman, co-creator of LeSS, recently wrote a riveting article about agility now featured on Scrum Alliance Spotlight. The article, entitled “Less Agile or LeSS Agile?” reminds readers of the beginning moments of agile and how this word was selected because it fundamentally described a condition of being able to adapt quickly to change.

About that founding meeting, he quotes Martin Fowler as saying, “We considered a bunch of names, and agreed eventually on “agile” as we felt that captured the adaptiveness and response to change which we felt was so important to our approach.” Larman continues to elaborate on how this agility is not meant to be a practice solely for the purpose of “creating more efficient teams who deliver high-quality faster,” although of course this is a natural outcome when teams are agile.

But he takes the concept to a deeper level. He writes, “I like to say that the goal of agile approaches, including Scrum, is to discover successful solutions by being able to … turn on a dime for a dime.”

Therein lies the beauty of being agile. When we are discovering successful solutions and implementing them quickly, even with very little planning, then we are embracing the fundamental essence of agility.

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

The post Article Review: Craig Larman – Less Agile or LeSS Agile? appeared first on Agile Advice.

Categories: Blogs

The Case for and Against Estimates, Part 4

Johanna Rothman - Thu, 06/09/2016 - 22:34

When we think about the discussion about estimates and #noestimates, I have one big question:

Where do you want to spend your time?

In projects, we need to decide where to spend our time. In agile and lean projects, we limit the work in progress. We prefer to spend our time delivering, not estimating. That’s because we want to be able to change what we do, as often as we can. That is not appropriate for all projects. (See When is Agile Wrong for You?)

In some projects, as in the domain that Glen Alleman has commented on in the first post in this series, it might well be worth spending enough time to generate reasonable estimates and to have an idea about how much the estimate might be off. 

In some projects, as in the gather-a-bunch-of-people-across-the-universe that David Gordon discusses in Part 2 of this series, you might need the exercise more of “who will deliver what” first, and then ask “when.” 

For both of those kinds of projects (I might call them programs), the cost of people going open-loop is too high. Of course, I would do an everyone-in-the-room planning session for the first month to iron out our deliverables. (When people tell me the cost of that is too high, I remind them about the cost of not delivering.) It’s possible if people understand how to use agile and lean to deliver at least as often as once a month, we don’t need more planning sessions. (If you want to run a program in an agile and lean way, see my program management book.)

In my experience, many people work on one- or two-team projects. The organization has decided on those projects. If you use agile and lean,  you might not need to estimate, if you deliver something every day. The delivery builds trust and provides sufficient feedback and the ability to change.

Here’s the way I like to think about #noestimates:

Noestimates is not about not estimating. It’s about delivering value often enough so you don’t have to estimate. You can spend time on different activities, all leading to delivering product.

I don’t buy what some #noestimates people say, that estimation is a sign of dysfunction. I have found the estimation process useful, as I explained in part 3 of this series.

In both Glen’s and Dave’s examples, it’s quite difficult to deliver value often, especially at the beginning of a program. Sure, you might decide to limit work in progress, or work in one- or two-week iterations. But the value you can deliver? Wow, the projects are so large and dispersed, it’s quite difficult to see value that often. You might see pieces of value. One vendor produces a proof of concept. Maybe another integrates two small chunks. That’s probably not enough value for people to see the product evolve.

On the other hand, when I can use an agile and lean approach for programs, I have been successful in delivering working product across the program every day. If you have SaaS, you can do this. I have done this with the software part of the program for a software/hardware product. That was valuable for everyone on the program.

When I think in #noestimate terms, I think of showing value for the entire product.

Here’s an example from my work. I write in small chunks. Okay, these blog posts have been massive. Not what I normally do on a daily basis. Because I write in small chunks, I can make progress on several books in the same week. That’s because I only have to finish a few paragraphs and I can be done with that part.

When I develop new workshops, I often start with the simulation(s). Once I know the activities, it’s even easier to design the debriefs and the material. I might take several days to develop a simulation. I call them drafts. I can do a draft in about an hour. The draft has value because I can ask people to review it. It’s a small deliverable.

In general, I timebox my work to finish something valuable in an hour. That’s because I make my deliverable small enough to show value in an hour. That’s the same idea as having a size “one” story. For you, a 1 might be a morning, but it’s probably not an entire day.

Back when I wrote code for a living, I was not good enough to deliver in  hour-long chunks. Maybe if I’d used TDD, I could have. I found estimation helpful. That’s why I worked in inch-pebbles. I could still show value, and it might not be several times a day. It was always at least every other day.

When I was a tester, I was good enough to write very small code chunks to test the product. That’s when I realized I’d been working in too-large chunks as a developer. When I was a manager, I tried to timebox all meetings to 50 or 55 minutes. I didn’t always succeed, but I was successful more often than not. Some meetings, such as one-on-ones, I timeboxed to 20 minutes.

In my work, I want to show value as early and as often as possible.  When I work with teams and managers, that’s part of my work with them.  Not because delivering something in an hour is the goal. It’s because the faster you deliver something, the more value you show. The faster you can get feedback and know if you are on the right track.

I have found it helpful to create an order of magnitude estimate for a project, so we all understand the general size/cost/duration of the project. Then, I start to deliver. Or, if I’m leading the team in some way, the team delivers.

The smaller the deliverable, the more often  you can get feedback and show value. I have seen these benefits from working this way:

  • The project ended earlier than we expected. That’s because we delivered “enough” to satisfy the PO/customer. (I’ve seen this many times, not just a couple of times.) If we had spent more time generating a detailed estimate, we would not have delivered as quickly.
  • We learned enough about the deliverables that we were able to do more discovery (as Ellen Gottesdiener says) as we delivered. We made the whole requirements process continuous and just in time. We did not require hour-long pre-sprint planning meetings. (Okay, that’s only happened twice. I have hope for more experiences like this.)
  • We were able to fix things before they got too large. We’d started in one direction on a feature set, realized we were headed in the wrong direction and replanned what to do and how to do it.

To me, the idea of #noestimates is tied up in small chunks of value.

#Noestimates is not for everyone. Just as detailed estimation is not for everyone. Think about what is right for your context: your team, your project, and yes, your management.

The posts to now:

  • Part 1 talked about targets and order of magnitude estimates.
  • Part 2 discussed when estimates are not that helpful. I did not include bad management in this post. Managers who treat estimates as commitments are not helping anyone.
  • Part 3 is about when estimates are helpful.
  • Part 4, this post, is about #noestimates.

I’ll do a summary post, including a pointer to the original article in part 5.

Categories: Blogs

The Case for and Against Estimates, Part 3

Johanna Rothman - Thu, 06/09/2016 - 22:14

In Part 1, I discussed order-of-magnitude estimates and targets. In part 2, I said how estimates can be misused. In this part, I’ll discuss when estimation is useful. Here are several possibilities:

  • How big is this problem that we are trying to solve?
  • Where are the risks in this problem?
  • Is there something we can do to manage the risk and explain more about what we need to do?
Estimates can be useful when they help people understand the magnitude of the problem.

One of my previous Practical Product Owner students said, “We use story size to know when to swarm or mob on a story.” People tackle stories up to 5. (They use Fibonacci series for story size.) They might pair or swarm on stories starting at size 8. Even if they have a 21 (or larger) size story, they swarm on it and finish it in a couple of days, as opposed to splitting the story.

They use estimates to understand the size and complexity of the feature. (I would call their features “feature-sets,” but they like to call that one big thing a feature.)

You might not like that approach. I think it’s a fine way of not fighting with the PO to split stories. It’s also helpful to work together to solve a problem. Working together spreads knowledge throughout the team, as a team.

My experience with estimation is that it’s easy for me to not understand the magnitude of the work. We manage this problem in agile/lean by estimating together, or working together, or with timeboxing in some way.

The first time we solve a particular problem, it takes longer. The first time I worked on a control system (embedded software), I had to learn how things worked together. Where did the software interact with the hardware? What were the general risks with this kind of a product? The first time I self-published a book, everything took longer. What were the steps I needed to finish, in what order?

I worked on many control systems as a developer. Once I understood the general risks, my estimates were better. They were not sufficiently accurate until I applied the rules of deliverable-based planning. What deliverables did I need to deliver? (I delivered something at least once a week, even if it was data from what I now know is a spike.) What inch-pebbles did I need to create that deliverable?

The more I broke the work down into deliverables, the better the estimate was. The smaller the chunks, the better my estimate was. The more I broke the problem down, the more I understood what I had to do and what the risks were.

One of the things I like about agile and lean is the insistence on small chunks of value. The smaller my chunk is, the more accurate my estimate is.

Estimates can help people understand risks.

You’ll notice I talked a lot about risks in the above section. There are general project risks, such as what is driving the project? (See Manage It! or Predicting the Unpredictable, or a series I wrote a few years ago, Estimating the Unknown.) We optimize different work when we know what is driving the project. That’s the project view.

We have possible risks in many deliverables. We have the general risks: people get sick, they need to talk the duck, they multitask. But, each deliverable has its own risk.

I’ve said before software is learning, innovation. You may have done something like this project before, so you have domain expertise. But, you have probably not done this new thing here.

When I estimate, I start thinking about what I need to do, how to solve this problem. Then, I start thinking about the problems I might encounter in solving those problems.

I can’t get to the problems unless I have inch-pebbles. I am a big-picture person. I see the whole problem, possibly even the whole solution, and I skip some of the steps in my head. I estimate top-down as a start. Unless I create my inch-pebbles, I am likely to gloss over some of the risks because I start top-down.

You might not be like me. You might estimate bottom-up. You might see all the details. You might not miss any steps in solving the problem as you think about it. (I wonder about people like you: do you see the big picture at the beginning, or does it evolve for you?)

I have met some people who estimate inside out. They tell me they see part of the big picture and part of the small steps. They iterate on both parts until they see and can estimate the whole thing.

I have taught a number of estimation workshops. Most of my participants are top-down people. They see the result they want and then envision the steps to get there. I have met some small number who start bottom up. I have met two people who are inside-out. I don’t know if that’s a normal distribution, or just the people who participate in my workshops.

Estimates can help people understand possible first steps.

When people think about the first thing that can provide value, and they think about how to make that first thing small (either inch-pebbles or agile stories), they can more easily see what the first deliverable could be. They can discuss the deliverable progression (in agile with a product owner and in a more traditional life cycle with a project manager or a product manager).

I have found the discussion of deliverable progression very helpful. Many years ago, I was the lead developer for a gauge inspection system (machine vision on an assembly line). I asked the customer what he wanted to see first. “Can you see the gauge enough to give us some kind of an answer as to whether it’s a good gauge?” was his answer.

Notice he said “enough,” not “a perfect inspection.” We did a proof of concept in a couple of days. In the lab, with the right lighting, we had an algorithm that worked well enough. You might think of this as a discovery project. Based on that deliverable, we got the contract for the rest of the project. If I remember correctly, it took us close to 6 months to deliver a final system.

For that project, I acted as a cross between a project manager and what we now call a product owner. We had release criteria for the project, so I knew where we were headed. I worked with the customer to define deliverables every two weeks, after showing a demo of what we had finished every two weeks. (This was staged delivery, not agile. We worked in week-long timeboxes with demos to the customer every two weeks.)

This is in the days before we had project scheduling software. I drew PERT diagrams for the customer, showing date ranges and expected deliverables.

A few years ago, I coached a project manager. She was the Queen of the Gantt. She could make the Gantt chart do anything. I was in awe of her.

However, her projects were always late—by many months. She would work with a team. They would think it was a six-month project. She would put tasks into the Gantt that were two-, three-, and four weeks long. That’s when I understood the problem of the estimation unit. “If you measure in weeks, you’ll be off by weeks.” Her people were top-down thinkers, as I am. They glossed over some of the steps they needed to make the product work.

I explained how to do deliverable-based planning with yellow stickies. The people could generate their tasks and see their intersections and what they had to deliver. She and the team realized they didn’t have a 6-month project. They had a project of at least a year, and that was if the requirements didn’t change.

When they started thinking about estimating the bits, as opposed to a gross estimate and applying a fudge factor, they realized they had to spend much more time on estimating and that their estimate would be useful. For them, the estimation time was the exploration time. (Yes, I had suggested they do spikes instead. They didn’t like that idea. Every project has its own culture.)

How do your estimates help you?

Maybe your estimates help you in some specific way that I haven’t mentioned. If so, great.

powerlawdistributionThe problem I have with using estimates is that they are quite difficult to get right. See Pawel Brodzinski’s post, Estimation? It’s Complicated… In

In Predicting the Unpredictable, I have a chart of how my estimates work. See the Power Law Distribution: Example for Estimation. (In that book, I also have plenty of advice about how to get reasonable estimates and what to do if your estimate is wrong.)

In my measurements with my clients and over time, I no longer buy the cone of estimation. I can’t make it work for agile or incremental approaches. In my experience, my estimates are either off by hundreds of %, or I am very close. We discover how much I am off when the customer sees the first deliverable. (In Bossavit’s Leprechauns of Software Engineering, (or on leanpub) he says the cone of estimation was never correct.)

For me, deliverables are key to understanding the estimate. If, by estimating, you learn about more deliverables, maybe your estimation time is useful.

Since I use agile and lean, estimating time for me is not necessarily useful. It’s much more important to get a ranked backlog, learn if I have constraints on the project, and deliver. When I deliver, we discover: changes in requirements, that we have done enough, something. My delivery incorporates feedback. The more feedback I get, the more I can help my customer understand what is actually required and what is not required. (I often work on projects where requirements change. Maybe you don’t.)

I realized that I need a part 4, that specifically talks about noestimates and how you decide if you want to use noestimates. Enough for this post.

Categories: Blogs

What is Agile Leadership?

Agile Management Blog - VersionOne - Thu, 06/09/2016 - 14:30

What is agile leadership?Have you ever faced one of the following challenges with your agile adoption?

  • Executive teams who want you to be agile, but still require all the traditional metrics and reporting
  • Middle managers who feel threatened by agile and seem to be working against you
  • An organizational culture that seems to run counter to an agile way of working

If you are experiencing any of the issues above you are not alone. After working with hundreds of organizations and thousands of people these are the most common themes that have emerged. Rather than giving up on your agile adoption, it’s time to bring agility to your organization’s leadership team. You need agile leadership. Let’s examine why…

In any business there are two main roles; people working “in” the business and people working “on” the business. Agile methods, like Scrum, do a great job of addressing the roles and responsibilities of people “working in the business”. For example, Scrum says that we need a product owner; someone responsible for guiding the team to build the right product to meet the needs of the stakeholders. Most agile methods however, do not address the roles and responsibilities of those “working on the business” – AKA “management”.

Some agile experts have taken a stand and said that we don’t need “management”, that we should fire anyone with a leadership title. That is one view, albeit an unfortunate one. Another view is that we need people who are fully dedicated to; planning and setting a vision, building an agile culture, and supporting those doing the work.

My colleague Pete Behrens says that “agile leadership” is the glass ceiling that prevents our organizations from becoming agile. We need to break through this ceiling if we are to build truly agile organizations.

Now that we have examined why we need agile leadership, let’s define what it is…

To come up with a definition, I first looked at the values of the Agile Manifesto (http://www.agilemanifesto.org). In order to be an agile leader we need to:

  • Remember that it’s all about the people (individuals and interactions)
  • Focus our efforts on delivering business value (working product)
  • Form and respect the partnership with our clients (customer collaboration)
  • Plan and be willing to react in the moment (responding to change)

I also examined some of the fundamental principles of agility:

  • Transparency – When I graduated from college I worked for a small startup. One day they called us into the conference room to let us know the company was in dire financial trouble. At this point we were so far into the red that people had to be impacted. The owners of the company felt like they were protecting us from this knowledge. Because we didn’t know the company’s financial situation, we couldn’t do anything to help them. Agile leaders work hard to be open and honest with their communication. They make sure that all needed information is out in the open and easily accessible.
  • Continual feedback – Agile leaders abhor practices like the annual performance review. Instead of bottling up feedback and delivering it all in one fell swoop. Agile leaders provide feedback in the moment where it can add the most value.
  • Inspect and adapt – Agile leaders use retrospectives to frequently pause and examine the output of the team and the way that the team works together. These retrospectives allow for everyone to get better at a more expedient pace.
  • Embrace failure – By running short low risk experiments and “failing” we learn rapidly. An agile leader sees failure as an opportunity for their teams to grow, not something that should be prevented at all costs.

Finally, there are few practices I have learned:

  • Be a servant leader – Key tenants of servant leadership include; taking care of needs not wants, building and using influence rather than abusing power, and leading by example.
  • Focus on strengths – Agile leaders get to know their team members on a deeply personal level, which allows them to know a team members strengths and weaknesses. Rather than focus on the losing battle of shoring up weaknesses, agile leaders focus on building strengths instead.
  • Be vulnerable – I used to think that emotional intelligence meant stopping our bodies natural reactions to stimuli and choosing to react in an “appropriate” way. Now, I know that stopping and bottling up emotions only leads to health problems. Agile leaders are comfortable with expressing their emotions in front of their team. They realize that “being real” leads to strong relationships and greater team intimacy.

Combining what the Agile Manifesto, Agile Principles, and my own experience; I came up with the following definition of an agile leader…

“Agile leaders are inclusive, democratic, and exhibit a greater openness to ideas and innovations. With a passion for learning, a focus on developing people, and a strong ability to define and communicate a desired vision, they possess all of the tools necessary to successfully inspire others and become an agent for change within any organization.” – Center For Agile Leadership

Would you like to meet a real life agile leader? I would like to introduce you to Joe Kirk (https://www.linkedin.com/in/mrjoekirk), CIO at the Tennessee Department of Transportation. Joe has built a truly agile organization. A few of his major accomplishments include:

  • Shifted his departments culture from one where everyone couldn’t wait to retire, to one where everyone can’t wait to complete their next sprint
  • Built out co-working spaces so that his teams can collaborate
  • Recently hosted an innovation day that produced several promising product ideas

Wondering how you can become an agile leader yourself? Or perhaps you know a leader who wishes they could be more agile?

There are a number of new offerings coming onto the market today, such as our Certified Agile Leader® program. Also, in April 2016 the Scrum Alliance announced their new Certified Agile Leadership program, which follows a similar pattern to our program. We hope that there will soon be a convergence of the two programs, since they have the same goal in mind. To learn more about becoming an agile leader please visit http://www.centerforagileleadership

The post What is Agile Leadership? appeared first on The Agile Management Blog.

Categories: Companies

WIP, Capacity, and Dirty Laundry

NetObjectives - Thu, 06/09/2016 - 13:05
A benefit of being a CIO is that you get to collect a treasure chest of war stories to share with other CIO’s.  These stories also serve a purpose:  They teach patterns to watch out for (so that if nothing else, you learn when to cringe.) One of my war stories goes like this.  Outside my glass-walled office, in plain view from my desk, is an operational dashboard that shows concurrent users, and...

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

Managing to Lead

Leading Agile - Mike Cottmeyer - Thu, 06/09/2016 - 12:30

Every week I have to get ready for my call with my coach and it is unlike almost everything else I do. Every other conversation I have is, if not predictable, then at least familiar territory. Not so with my coach; the conversation can quickly go somewhere unexpected and nearly always does. The discovery is usually fun and I come away feeling energized with a new perspective.

I am reminded every time I’m preparing, of the Zen Master and the teacup.  As the story goes, a successful businessman seeks wisdom from a Zen Master who then pours tea for him until it overflows and spills on his suit. The man complains, and then the master replies that his mind too is full like the teacup with all that he thinks he already knows. He is admonished and is told he must leave and not return until he can empty his mind and make room for wisdom.

Managing to Lead

I’ve known my coach for many years…almost two decades…and you might think the challenge of emptying my cup would get easier, but it doesn’t. The rituals help, and the familiarity with my coach helps, as does his natural way of bringing some sense of ease and acceptance to even the most challenging life conversations. But almost like meditating, working towards an empty cup is a shift in thinking that always feels new again.

As an agile coach, I am obliged to pay closer attention. I have empathy for the people I am working with because I know how disorienting it can feel to continually be learning something new. The skill of agility is far more than just the rituals of agile. And similarly, servant leadership in particular is more about who we are for other people than it is about management rituals like status reports. There is far more to being agile than methodology or process.

The way we learn it is completely different too. Every day is learning and all the while, every day is also important to successful team delivery. It seems like there are never any breaks in the action. It is truly challenging and so much more than the kind of learning we all did in school. It is not a matter of learning something just in order to pass a test, or learning some skill…calculus??…that I may or may not use some day. It is something we need to learn and apply while we are learning it. It is learning that matters right here, right now, every day.

“Certainty is not proof of truth.”

–  Maturana & Varela Tree of Knowledge

Some people have more of a challenge than others. Surprisingly, or maybe not so surprisingly, the more successful the person, the more often they have trouble. In my many years as an agile coach, I’ve heard countless times “that won’t work here”, only to see it in successful practice 6 months or a year later. Many of the skills of an effective servant leader fly in the face of traditional management. Seasoned managers in particular seem to have a tough time acquiring this new skill of being open to possibilities.

Before Industrialization there was craftsmanship and skill and dedication to the unique needs of each customer. With industrialization came efficiency, management and the pursuit of volume. The need for same-ness was equated with quality. The values of craftsmanship and the art of everyday skillful delivery gave way to volume, predictability and consistency.

With today’s knowledge workers, unique innovative solution-making is less about being managed for volume or velocity and more about being inspired with a clarity of vision, a great team of other craftspeople, and a deep understanding of what each customer really needs and wants. Leaders need to help create a clearing for their people to try new things, invent and feel safe doing so. It should be baked in to the teams capacity expectations.

Agility is really more of a personal, team and organizational skill than a methodology or a process. Learning about it requires learning some new distinctions. Rituals like standups, demo’s and exploratory testing are one thing, but code smells and anti-patterns are another. And we have to learn real-time through experimentation every day.

Leading knowledge workers requires very different skills than that of traditional management. Learning those skills requires a new posture to learning.

Remember when you were young and learning was energizing and fun? That is “beginner’s mind” and that is the state of having an empty cup. It is clear eyed, buoyant and curious rather than having “the answers”, and that is the state of discovery we are after. But it won’t happen without recognizing in ourselves, real-time, every day, that we need to adopt this new posture. At first it will feel uncomfortable, but with practice it will begin to feel exciting and fun and not knowing what will happen is part of the fun.

Making a transition from manager to leader means learning to see the world anew. It can feel vulnerable to no longer rely on what has worked for us in the past. We can take solace knowing that we are not the first and we are not alone. Success as a leader today means constant learning; even our coaches and mentors are all learning. The same is true when we are learning to be more agile. In many cases, it is time to empty our cup and simply become more open to the unfolding and discovery of something completely unexpected.

The post Managing to Lead appeared first on LeadingAgile.

Categories: Blogs

Agile is not magic

IceScrum - Thu, 06/09/2016 - 12:30
After years helping companies to adapt their practices and change their mindset toward agile values, a comment we hear very often is “Ok, we know that we don’t follow the recommendations… But our context is quite singular and Agile/Scrum is meant to adapt to everything, right? Thus, we adapt it to our context.”. Unfortunately, it…
Categories: Open Source

Delivering quality software with Agile

Ben Linders - Thu, 06/09/2016 - 10:32

Delivering quality software agile bits chips 2016My article on delivering quality software with Agile is featured in the first English edition of Bits&Chips, a news magazine for professionals who develop smart products and systems. A big thanks to the editorial staff and to Nieke Roos, editor-in-chief of Bits&Chips.

My article explores what agile teams can do to deliver quality software:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

To deliver high-quality products to customers, Agile teams and product owners have to jointly ensure the quality of the requirements and manage them effectively. Agile quality practices have to be ingrained in the team’s daily work. Ben Linders describes how it can be done.

For more than sixteen year Bits&Chips is publishing a magazine in Dutch, aimed at professionals in the Netherlands and the Flemish speaking part of Belgium. According to Nieke Roos, the English edition helps to reach the foreign knowledge workers in the region and to show the world about high tech development in the Netherlands and Belgium.

This English edition of Bits&Chips also featured the Software-Centric Systems Conference which was held on May 25 at the High Tech Campus in Eindhoven. I’m covering this conference for InfoQ.com, see my article on Technologies and Trends in Developing Complex Software Systems.

I’m proud to be part of this first English edition, after having several Dutch articles published in Bits&Chips.

Categories: Blogs

Regional Scrum Gathering Rio, Rio de Janeiro, Brasil, June 23-25 2016

Scrum Expert - Thu, 06/09/2016 - 10:00
The Regional Scrum Gathering in Rio de Janeiro is the largest Scrum event in Latin America. In 2014, it received about 500 people and discussed topics like Scrum, Kanban, Lean, Agile and Lean Startup in lectures, workshops and open spaces. In the agenda of the Regional Scrum Gathering Rio conference, you can find topics like “Software Factory or People Factory?”, “Is Estimating a Crime?”, “Are We Really Being Agile? – Agile Patterns and Anti-Patterns”, “How coaching had helped to change my company”, “Complexity is dead: at least for the end user”, “What Type of Contract to Use in Agile Projects”. Web site: http://www.scrumrio.com/ Location for the Regional Scrum Gathering Rio conference: Windsor Atlantica Hotel, Avenida Atlântica 1020, Copacabana, Rio de Janeiro, 22010-000, Brazil
Categories: Communities

In Memory of Jean Tabaka

Leading Agile - Mike Cottmeyer - Thu, 06/09/2016 - 03:41

I debated writing this post.

I considered Jean a friend.

Even though we didn’t talk often, I think she considered me a friend.

I’m sad she passed away this week.

I’d like to share a story with you guys.

When I wanted to start LeadingAgile, I was scared. I didn’t have the 100K in the bank Mitch Lacey told me I needed to start. I didn’t have space on my credit cards to fund myself for a few months. What I had were a few good relationships.

Jean was one of them.

I called Jean one day and told her what I wanted to do. She gave me good counsel. I wanted to see if I could get on Rally’s subcontractor list. I had worked for VersionOne so that was complicated. Jean went to bat for me.

Getting on Rally’s subcontractor list gave me the confidence to step out.

Even thought I never did any work for Rally, having that option in my back pocket created sufficient safety for me that I was able to be brave. Jean helped me be brave. For that I will be forever in her debt.

Who knows how things would have turned out had Jean not helped me.

I like to think I could have done it without anyone’s help.

But Jean helped.

I’ll miss Jean Tabaka forever.

Thank you Jean.

May you rest in peace.

The post In Memory of Jean Tabaka appeared first on LeadingAgile.

Categories: Blogs

Elasticsearch Throttling Indexing

Recent adventures in Zapierland had me in a somewhat scary predicament. Starting at some point last week I’d get an alert that the Elasticsearch cluster we run Graylog against had hit very high CPU, load and memory usage. I was confused… we had more than enough horsepower to handle queries and normally the cluster only uses about 10% of CPU on each node. I paused message processing (that’s a nice feature of graylog there, it just sticks the messages into a local journal) and began looking around. Nothing seemed off. Nothing stuck out in the logs. I noticed that the CPU and load eventually dropped, shrugged my shoulders and resumed message processing. Maybe a rogue query? Who knows.

A couple days later it happened again. Pause, resume. Everything began operating normally. While I had some hunches I had no solid evidence as to the cause and assumed that maybe it was time to expand the cluster. Since it wasn’t a fire (we just use graylog for internal log searching of API requests) I added a card to our trello board to just go ahead and kill two birds with one stone by upgrading Graylog and ES and ensuring we up the cluster size in the rebuilt cluster. I can handle the pause/unpause cycle in the short term.

As it continued happening daily, I got very curious. It only happened during peak load time and when there were a lot of staff members using it. And it always became 100% fine with a pause/unpause messaging cycle. I looked around some more and realized that we should tune the logging level a bit and see if anything stood out the next time it hit.

Sure enough, when our engineering team did a quick support blitz it happened again. This time the Elasticsearch logs were filled to the brim with entries like the two below.


[2016-06-06 18:20:34,880][INFO ][index.engine ] [ip-10-0-0-2.ec2.internal] [graylog2_761][0] now throttling indexing: numMergesInFlight=5, maxNumMerges=4
[2016-06-06 18:20:40,804][INFO ][index.engine ] [ip-10-0-0-2.ec2.internal] [graylog2_761][0] stop throttling indexing: numMergesInFlight=3, maxNumMerges=4

Well that’s a bit curious. Off to google. After a little searching I came across this entry in the elasticsearch reference.

Segment merging is computationally expensive, and can eat up a lot of disk I/O. Merges are scheduled to operate in the background because they can take a long time to finish, especially large segments. This is normally fine, because the rate of large segment merges is relatively rare.

But sometimes merging falls behind the ingestion rate. If this happens, Elasticsearch will automatically throttle indexing requests to a single thread. This prevents a segment explosion problem, in which hundreds of segments are generated before they can be merged. Elasticsearch will log INFO-level messages stating now throttling indexing when it detects merging falling behind indexing.

Elasticsearch defaults here are conservative: you don’t want search performance to be impacted by background merging. But sometimes (especially on SSD, or logging scenarios), the throttle limit is too low.

A key point following that statement is the revelation of what the default rate is.

The default is 20 MB/s, which is a good setting for spinning disks. If you have SSDs, you might consider increasing this to 100–200 MB/s.

Well this seems promising because we DO use SSD. From the documentation I issued a curl call to up the indices.store.throttle.max_bytes_per_sec rate.

PUT /_cluster/settings
{
    "persistent" : {
        "indices.store.throttle.max_bytes_per_sec" : "100mb"
    }
}

With these settings in place I had a few hours until the next support blitz. Suffice to say it has been several days and we haven’t had to pause message processing yet. This is definitely an important setting to ensure you configure correctly when you tune the defaults on your cluster.

Categories: Blogs

Knowledge Sharing


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