Skip to content

Feed aggregator

Discussion on Technical Debt

TV Agile - Mon, 07/28/2014 - 23:31
At the SATURN 2014 conference, Jeromy Carrière of Google, Philippe Kruchten of the University of British Columbia, Robert L. Nord of the Carnegie Mellon Software Engineering Institute, Michael Keeling of IBM and Rebecca Wirfs-Brock discuss about technical debt. The discussion is moderated by George Fairbanks of Google. Video producer: http://www.sei.cmu.edu/
Categories: Blogs

No Slack = No Innovation

J.D. Meier's Blog - Mon, 07/28/2014 - 20:23

"To accomplish great things we must dream as well as act." -- Anatole France

Innovation is the way to leap frog and create new ways to do things better, faster, and cheaper.

But it takes slack.

The problem is when you squeeze the goose, to get the golden egg, you lose the slack that creates the eggs in the first place.

In the book The Future of Management, Gary Hamel shares how when there is a lack of slack, there is no innovation.

The Most Important Source of Productivity is Creativity

Creativity unleashes productivity.  And it takes time to unleash creativity.  But the big bold bet is that the time you give to creativity and innovation, pays you back with new opportunities and new ways to do things better, faster, or cheaper.

Via The Future of Management:

“In the pursuit of efficiency, companies have wrung a lot of slack out of their operations.  That's a good thing.  No one can argue with the goal of cutting inventory levels, reducing working capital, and slashing over-head.  The problem, though, is that if you wring all the slack out of a company, you'll wring out all of the innovation as well.  Innovation takes time -- time to dream, time to reflect, time to learn, time to invent, and time to experiment.  And it takes uninterrupted time -- time when you can put your feet up and stare off into space.  As Pekka Himanen put it in his affectionate tribute to hackers, '... the information economy's most important source of productivity is creativity, and it is not possible to create interesting things in a constant hurry or in a regulated way from nine to five.'”

There is No “Thinking Time”

Without think time, creativity lives in a cave.

Via The Future of Management:

“While the folks in R&D and new product development are given time to innovate, most employees don't enjoy this luxury.  Every day brings a barrage of e-mails, voice mails, and back-to-back meetings.  In this world, where the need to be 'responsive' fragments human attention into a thousand tiny shards, there is no 'thinking time.'  And therein lies the problem.  However creative your colleagues may be, if they don't have the right to occasionally abandon their posts and work on something that's not mission critical, most of their creativity will remain dormant.”

Are People Encouraged to Quietly Dream Up the Future?

If you want more innovation, make space for it.

Via The Future of Management:

“OK, you already know that -- but how is that knowledge reflected in your company's management processes?  How hard is it for a frontline employee to get permission to spend 20 percent of her time working on a project that has nothing to do with her day job, nor your company's 'core businesses'?  And how often does this happen?  Does your company track the number of hours employees spend working on ideas that are incidental to their core responsibilities? Is 'slack' institutionalized in the same way that cost efficiency is?  Probably not.  There are plenty of incentives in your company for people to stay busy.  ('Maybe if I look like I'm working flat out, they won't send my job offshore.')  But where are the incentives that encourage people to spend time quietly dreaming up the future?”

Are you slacking your way to a better future?

You Might Also Like

Innovation Quotes

The Drag of Old Mental Models on Innovation and Change

The New Competitive Landscape

The New Realities that Call for New Organizational and Management Capabilities

Who’s Managing Your Company

Categories: Blogs

3 Challenges to Help You Set New Benchmarks in Innovation

J.D. Meier's Blog - Mon, 07/28/2014 - 19:39

If you want to change your game, you need to know what the key challenges are.

Innovation is a game that you can play much better, if you know where and how to debottleneck it.

In the book The Future of Management, Gary Hamel shares 3 challenges that he believes can help you unleash your organization’s capacity for innovation.

  1. How can you enroll every individual within your company in the work of innovation, and equip each one with creativity-boosting tools?
  2. How can you ensure that top management's hallowed beliefs don't straightjacket innovation, and that heretical ideas are given the chance to prove their worth?
  3. How can you create the time and space for grassroots innovation in an organization that is running flat to deliver today's results?

According to Hamel, "Make progress on these challenges and your company will set new benchmarks in innovation."

If I think back through the various teams I’ve been on at Microsoft, one team that I was on was especially good at helping innovation flourish, and we were constantly pushing the envelope to “be what’s next.”   Our innovation flourished the most when we directly addressed the challenges above.  People were challenged to share and test their ideas more freely and innovation was baked into how we planned our portfolio, programs, and projects.

Innovation was a first-class citizen – by design.

You Might Also Like

High-Leverage Strategies for Innovation

Innovation Life Cycle

Lessons Learned from the Most Successful Innovators

The Drag of Old Mental Models on Innovation and Change

The New Realities that Call for New Organizational and Management Capabilities

Categories: Blogs

Hansoft 8 Brings Actionable Agile Metrics

Scrum Expert - Mon, 07/28/2014 - 17:22
Hansoft brings Actionable Agile Metrics to developers, managers and executives with the release of Hansoft 8. Hansoft 8 combines Program Management with Business Intelligence in one tool. Decision making on all levels, from the team to the program and portfolio, can now be supported by relevant data visualized with iterative and collaborative dashboards. “Agile metrics is a hot topic right now and we can see how many large organizations realize that critical decision making happens on all levels every day, not only in top management group. Yet the traditional business intelligence ...
Categories: Communities

Why Agile Is Failing in Large Enterprises, And What You Can Do About It

Leading Agile - Mike Cottmeyer - Mon, 07/28/2014 - 17:13

Here is the deck from my Agile2014 talk on why many folks are struggling to adopt agile in larger, more complex enterprises. The presentation explores many themes persistent on this blog. Why agile works, why agile fails, what gets in the way, and how to systematically and pragmatically begin to refactor your legacy organization into an effective agile enterprise? If you came to the talk, I appreciate it. If you have any questions, please let us know. Thanks!

Why Agile Is Failing in Large Enterprises, And What You Can Do About It from Mike Cottmeyer

The post Why Agile Is Failing in Large Enterprises, And What You Can Do About It appeared first on LeadingAgile.

Categories: Blogs

Montreal Agile Game Development Courses, September 17th - 19th

Agile Game Development - Mon, 07/28/2014 - 16:03
I'm teaching two public courses on agile game development in Montreal this September:

Certified ScrumMaster for Video Game Development

Kanban for Video Game Development


Categories: Blogs

Performance appraisals without a number!

Growing Agile - Mon, 07/28/2014 - 15:00

Below are my slides for my Agile 2014 talk: Agile Performance Appraisals without a number. If you missed the session is was recorded, so the video should be available on the Agile Alliance site in a few weeks.

Categories: Companies

At Agile2014 in Orlando. Good to be back!

TestDriven.com - Mon, 07/28/2014 - 14:37
The last time I attended the Agile Conference was in 2008 when I presented a workshop on Build/Test Grids and Selective Testing. I am happy that in the last few years there has been a lot of development in this space. For example, Solano Labs has a compelling offering that works both as SaaS and […]
Categories: Communities

The 4-Step Action Plan for Agile Health: Step 2. Understand how to adopt healthy Agile Mindset Practices and Lean Practices

Agile Management Blog - VersionOne - Sun, 07/27/2014 - 17:01

Agile development requires a cross-functional, self-organized team to deliver potentially shippable software at the end of each sprint, with analysis, design, code developing and testing activities going on concurrently (not sequentially) within each sprint.      Combining Agile/Scrum development with some of the lean methods is also becoming popular (so-called “Scrumban” methods). These methods emphasize reducing Work In Process (WIP), reducing feature cycle time and increasing throughput (feature completion rate).

In my blog on From Agile Pathologies to Agile Health I explained that some “agile” teams suffer from the following common pathologies, i.e., major dysfunctions in practicing agile methods, while claiming that they are “doing agile”:

  1. Agile development “sprints” assigned to software development lifecycle phases
  2. Agile development “sprints” assigned to technology tiers
  3. Mini-Waterfall inside sprints
  4. Water-Scrum-Fall

While an agile team may not be exhibiting gross dysfunctions (pathologies) listed above, it may still behave in harmful or unhealthy ways that would prevent it from realizing the benefits of agile development, such as higher productivity, throughput and quality.    Absence of major pathologies or sickness doesn’t imply health; agile teams may still not be healthy due to one or more harmful behaviors.

In this 4-part blog series, I focus on 6 harmful behaviors exhibited by agile teams and how to move away from them, and transition to 6 healthy agile-lean practices in order to get more benefits (improved productivity, throughput and quality).  I also present 4 specific steps to transition to healthy agile-lean practices.   Table 1 summarizes these 4 steps, and labels 6 harmful behaviors (as 1B through 6B) and 6 healthy agile-lean practices (as 1P through 6P) for ease of cross-referencing. Table 1 also indicates what is covered in each of the 4 parts of the blog series: Part 1 (highlighted in light green color) was completed.    In this Part 2 (highlighted in pink color in Table 1), Step 1 – understand healthy “Agile Mindset” practices (1P and 2P) and 2 lean practices (3P and 4P) – is described.  Parts 3 and 4 will be presented in the future.

Table 1: The 4-Step Action Plan for Agile Health

R_Part2_Table1

“Agile Mindset” practices to improve agile health:  I now explain and recommend 2 specific practices to embrace an “agile mindset.”   I typify an agile team B that consists of a business analyst, 3 full-time developers, 2 full-time QA testers, a Product Owner and a ScrumMaster.   All members of Team B are full-time, dedicated members unlike the Struggling Agile Team of Part 1 of this blog series which had part-time, multiplexed members.   As Team B follows all 6 healthy agile-lean practices (1P to 6P) listed in Table 1, it is our prototypical “Healthy Agile Team”.

I use a similar example of a typical 4-week (20 workdays) sprint for the Healthy Agile Team.   Figure 1 illustrates the Sprint History Map of this 4-week sprint after the sprint is over.   It uses the same format and legend as used in in the Sprint History Map of the Struggling Agile Team (see Figure 1 of Part 1). Each feature was broken down into its implementation tasks either during sprint planning or actual sprint execution.  These tasks are indicated in the legend at the bottom of Figure 1.

R_Part2_Figure1

Figure 1: Sprint History Map of the Healthy Agile Team following the
Agile Mindset Practices

The 2 “Agile Mindset” practices (numbered 1P and 2P below) require replacing the legacy mindset with agile mindset, moving away from silo thinking, welcoming the change necessary for successful agile adoption and implementing the required change to get the benefits of higher productivity, throughput and quality.

1P. Full-time, dedicated agile team members without multiplexing and with minimal multitasking: Move away from the old mindset that treats people as resources whose utilization needs to be maximized via multiplexing and multitasking.   It is much more important that you maximize agile team throughput than worry about utilization of each team member as a resource.

Assign agile team members to work full time (100%) on a single agile team through all sprints of at least one release cycle.  You need at least a full release cycles (4 to 6 sprints) for team members to understand each other’s strengths and weaknesses, develop a (hopefully smooth) working relationship, and jell together as a team.  These well-jelled team members show higher productivity as they learn how to capitalize on each member’s strengths and compensate for weaknesses.  They learn to work with each other as human beings, and not replaceable resources.  This often requires a significant buy-in from management, if it is steeply rooted in traditional project management practices.

Cultivate the habit of doing focused work – one task at a time – starting with 30 minutes of uninterrupted work on a single task, and gradually extending it up to two hours.  Then you will need a well-deserved 5-minute break due to intellectual fatigue.  See The Energy Project: http://theenergyproject.com/  to understand how to conserve your energy to work in a highly focused way on single task at a time. Each team member learns to focus on a single task at a time (up to 2 hours in a stretch) until the task is over, before switching to other tasks.

Avoid multiplexing and minimize multitasking.  It increases productivity by avoiding wasteful context switching, and making each team member committed to and accountable for the success of a single team.  There are no divided loyalties of a person among different teams and projects.  That simply doesn’t work well.

2P. Cross-Functional Team Members: An agile team is composed of cross-functional team members: Train, cultivate and invest in each member to become a “Master of One and Jack of Two”.   Each member has primary expertise or mastery in at least one area, and working level skills in two other areas.  From time to time, each person is needed to work in areas outside his/her own mastery.  For example, a developer tests features developed by other developers, or a tester develops scripts for automated tests, etc.   See: http://bit.ly/1lkaXHc.

Investing in team members to become “Master of One and Jack of Two” may require a significant buy-in from functional or departmental managers.   Team members don’t just do their own tasks that match with their primary expertise or interest.  They swarm as a team to deliver working features within each sprint. Each feature is worked on by a logical feature team swarming to complete the feature in the shortest cycle time.  See: http://bit.ly/1rhtV6g.  Although the Sprint History Map for the Healthy Agile Team (Figure 1) shows swarming feature teams only for Feature 1 and 2 for brevity, they exist for all 8 features in the backlog.  These feature teams are “logical” teams in the sense that they may share one or more individual team members.

How to adopt two lean practices:  These 2 lean practices (labeled 3P and 4P in the list of 6 healthy agile-lean practices of Table 1) are described below.

3P. Stop-Starting-Start-Finishing and work under WIP limit: Form swarming features teams within an agile team to focus attention on getting each feature accepted by the Product Owner as soon as possible.  Without completing a feature or a task already in progress, resist the temptation to start working on a new feature or a new task.  Stop starting new things (features or tasks) before completing the things you have already started.  This is a good mantra for life too.   This practice will effectively allow a lower WIP limit in an informal way.

As explained by David Anderson in his book “Kanban: Successful Evolutionary Change to your Technology Business,” 2010, page 114, the WIP limit needs to be set up as 2 to 3 people per feature plus 2 to 3 to smoothen the impact of a blockage.   For an Agile team of 7 full-time, dedicated team members, the WIP limit can be set up as 3 + 2 = 5.   You will need to experiment with this number and adjust it empirically up or down based on the experimental results.  Progressively lowering WIP limits will bring out bottlenecks that need to be resolved.  Agile Lifecycle Management tools, such as VersionOne, help you visualize the Kanban workflow under WIP limits, and provide warnings if WIP limits are exceeded.  Learn how to work with smaller WIP limits.

As shown in the Sprint History Map (Figure 1), the WIPs on Day 2 through 17 (total 16 days) for 7 completed features (Feature 1 through 7) in the sprint are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 2, 2, 1, 1, with the average WIP = (46/16) = 2.875.    The WIPs on Day 2 through 17 (total 16 days) for all 8 features are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 3, 3, 2, 2, with the average WIP = (50/16) = 3.13, which is only slightly more than the WIP of 46/16 = 3.13 for 7 completed features.  The Healthy Agile Team has its focus on completing the work in progress before starting the new work by following the Stop-Starting-Start-Finishing mantra which reduces WIP.   The Healthy Agile Team has a smaller WIP compared to that of the Struggling Agile Team illustrated in its Sprint History Map (see Figure 1 in Part 1, and the WIP data for the harmful behavior 3B in Part 1).

4P. Focus on minimization of cycle time: Improve team’s throughput (features completion rate) with cross-functional team members, eliminate NT events by avoiding multiplexing and multitasking, and use of proper test automation tools (see Part 3 of this blog series).

Reducing WIP reduces the cycle time.    As shown in the Sprint History Map (Figure 1), the cycle times for the 7 completed features (Features 1 through 7) are 6, 8, 5, 7, 7, 8, 5 days, with an average cycle time of (46/7) = 6.57 days.   I will now use the well-known Little’s Law to calculate the average throughput (rate of feature completion and acceptance by product owner) of the Healthy Agile team.

Average Cycle Time = Average WIP / Average Throughput, or alternatively

Average Throughput = Average WIP / Average Cycle time

In the example of Healthy Agile Team, Average WIP = 46/16 (see Practice 4P above), and Average Cycle Time = 46/7 (as explained just above).

Therefore, Average Throughput = [(46/16) / (46/7)] = 7/16 features per day.

You may use the Sprint History Map (Figure 1) to visually verify that the Healthy Agile team has  delivered 7 accepted features (Features 1 through 7) in 16 actual work days of the sprint, confirming the average throughput of 7/16 features per day.  Sprint History Maps provide visual data for WIPs and Cycle Times, and visual verification of Little’s law.

The higher throughput of 7/16 features per day for the Healthy Agile Team (compared to the Struggling Agile Team’s throughput of 4/18 features per day) can be attributed to the facts that the team has moved away from harmful behaviors:  it has no NT events and substantially reduced number of  impediments (IMP events); it avoided multiplexing and minimized multitasking, gotten away from the silo mindset,  is practicing Stop-Starting-Start-Finishing lean mantra, has reduced long cycle times (average cycle time of only 6.57 days in a 16-workday sprint), and is practicing automated testing (as will be explained in Part 3 of this blog series).

Little’s Law is a powerful and versatile tool.  A change in any one of its parameters (WIP, Cycle Time and Throughput) is most likely to effect a change in one or both of the other two parameters.  You can reduce cycle time by reducing WIP while holding throughput constant.  Or you may increase throughput by decreasing cycle time as we have just seen.  There is a third option: a team may increase the average WIP (more work in parallel) and thereby increase the throughput, provided that the team can hold the average cycle time by increasing its intrinsic productivity by upgrading its skills via training and apprenticeship, getting more experienced members on the team, using various automation tools, increasing its design and code reuse, etc.   If any one of these 3 parameters needs to be corrected or improved, Little’s Law tells us exactly what to do to achieve the desired results.  Most of the time the goal is to increase throughput (without sacrificing quality) by reducing cycle time or by increasing team’s intrinsic productivity or both.   Bennet Vallet of Siemens Health Care presents a great case study of Kanban success providing the details of how to harness Little’s law to reduce the average cycle time, increase the average throughput and improve the release predictability.

Lean methods provide us additional options to reduce the cycle time, and thereby, increase the throughput.  Splitting large features into smaller features (they still must deliver value to customers) reduces the average cycle time.   How small should these features be?   Larman and Vodde suggest that for an N-week long sprint, each feature should take no more than N/4 staff-week of total effort (Reference: “Scaling Lean and Agile Development” by Larman & Vodde, 2009, page 120).  For the 4-week example sprint used in this blog series, it would be ideal if each feature takes no more than 4/4 = 1 staff-week or 40 staff-hours (or less) of total effort.  For a 2-week sprint, each feature should take no more than ½ staff-week or 20 staff-hours of total effort.

Furthermore, leveling the workload, i.e., having all features of roughly the same size also reduces the average cycle time.  Uneven sized sprint workload (small features intermixed with medium and large features in a sprint backlog) increases the average cycle time.

As shown in the Sprint History Map (Figure 1), the Healthy Agile Team has swarming feature teams; each feature team is working on multiple tasks of a feature concurrently.  For example, in the Sprint History Map (Figure 1), Software Design task (D) and Acceptance Test Development task (TD) were going on concurrently on Day 2, Code development task (C) and Acceptance Test Case execution task (TE) were going on concurrently on Day 4.  This swarming action also reduces the cycle time due to intense collaboration among the feature team members, their focus on completing the feature and getting it accepted as fast as possible.

Sprint pipeline: Learn and apply the Sprint pipeline practice where feature analysis and UI design work is done one timebox ahead of software design, coding, testing, defect fixing, acceptance testing.   This effectively allows two successive timeboxes for each sprint, but without adversely impacting throughput (it still produces working software at the end of each sprint).   With sprint pipeline, feature specification and UI design is in much better shape when a sprint starts, compared to trying to squeeze all work for a feature in a single time box where analysis or UI design may become bottlenecks.   In the Sprint History Map (Figure 1), there are no “A: Analysis” tasks at all, because the Healthy Agile Team is following the sprint pipeline well. 

Is your team facing the challenge of moving away from harmful “legacy mindset” and “non-lean” behaviors, and is interested in transitioning to the healthy “agile mindset” and lean practices?  I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

Part 1: Understand harmful legacy Mindset and Non-Lean behaviors to move away from

Stay tuned for these future parts of the blog series:

Part 3: Understand how to use additional enablers of Agile Health

Part 4: Develop and implement your customized plan for adopting healthy agile-lean practices

Categories: Companies

The Right Way to Do Scrum, but ...

NetObjectives - Sun, 07/27/2014 - 13:02
We Do Scrum-But I often hear people say “oh, we do Scrum but we don’t do …”.  This includes “we do Scrum, but we don’t have fully cross-functional teams.”  Or, “we do Scrum but management interrupts us all of the time with needed new functionality.” With the creation (and misunderstanding) of Kanban, we often hear “we do Scrum but we don’t have hard iterations, we follow more of a flow model.”...

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

Need Admin Tools And Reports For Your SaaS? Build A Separate Site

Derick Bailey - new ThoughtStream - Sun, 07/27/2014 - 02:46

In the last year, I’ve used command line tools to run various reports for SignalLeaf. It’s worked out well, but I’ve outgrown the usefulness of these reports.

It’s not that the reports themselves are no longer useful – but the format in which they are displayed, and the limited interactivity of them. I need to do more than just get some read only data. I need to also drill in deeper and get more information from accounts, users, podcasts, etc.

Separate admin site

I Don’t Want A /admin Route

I’ve been hesitant to add in a “/admin” route on SignalLeaf for a lot of reasons. Then a few weeks ago, it suddenly dawned on me – I don’t need to add a “/admin” route set to the main app itself. I can build a separate admin app, and have it focused 100% on the administrative tools, reports and dashboards that I need.

So that’s what I did over the last week or two. I set up a new website, with it’s own authorization configuration, dedicated entirely to my needs for administrative tools. It’s working out really well for me, too. I don’t have to worry about polluting the core SignalLeaf app w/ administrative tools. I don’t have to worry about re-deploying the core system when I change the admin tools. I don’t even have to worry about the admin tools crashing, because I’m the only one that will ever use them. If the admin tools crash, who cares. They are on a separate site, and will not affect the core of SignalLeaf at all.

Build A Separate Admin App

If you’re looking at building an administrative section of your SaaS or web application, you might want to think about creating a completely separate application. It’s been a real breath of fresh air for me and SignalLeaf.

Of course, I needed a good authorization system to handle the admin site. I want something simple to require authorization for all routes on the site, and I wasn’t quite happy with the ones that I was finding. Far too many authentication systems in NodeJS land claim authorization as well, then don’t deliver. So I built my own authorization system – mustBe – but that’s another blog post to come soon.

     Related Stories 
Categories: Blogs

Jean Tabaka at Agile 2013 — Buckle Up and Press Play.

BigVisible Solutions :: An Agile Company - Sun, 07/27/2014 - 01:24

Jean sits down with Dave Prior at the end of day two at Agile 2013, the intent is to to talk about the maturation of agile, and enterprise agility from her (well respected) perspective, and what begins as a conversation around her conference sessions evolves into something so much more powerful, and impossible to summarize.

The post Jean Tabaka at Agile 2013 — Buckle Up and Press Play. appeared first on BigVisible Solutions.

Categories: Companies

Interview with Tim Lister, Keynote at Agile 2013 – Forty Years of Trying To Play Well With Others

BigVisible Solutions :: An Agile Company - Sun, 07/27/2014 - 01:23

Tim Lister, co-author of “Walzing with Bears”,”Adrenaline Junkies and Template Zombies”and “Peopleware” was one of the keynote presenters during Agile 2013. Tim’s talk “Forty Years of Trying to Play Well With Others” was a big hit. In this interview Tim shares some of the highlights of his talk, including his opportunity to work on one of the very first WANG computers

The post Interview with Tim Lister, Keynote at Agile 2013 – Forty Years of Trying To Play Well With Others appeared first on BigVisible Solutions.

Categories: Companies

An Awesome Conversation on Agile Coaching With Lyssa Adkins and Michael Spayd

BigVisible Solutions :: An Agile Company - Sun, 07/27/2014 - 01:22

At Agile 2013, Lyssa Adkins and Michael Spayd co-presented a session focused on helping coaches develop conflict facilitation skills. In this interview they discuss what makes agile coaches different than other types of coaches and some key ideas from their presentation.

The post An Awesome Conversation on Agile Coaching With Lyssa Adkins and Michael Spayd appeared first on BigVisible Solutions.

Categories: Companies

Transformation Case Study Highlights

Agilitrix - Michael Sahota - Sun, 07/27/2014 - 00:44

I was fortunate to act as  a catalyst for a transformation of a 100 person departments. Here is an early release of a presentation summarizing my learnings.

Transformation Case Study Highlights from Michael Sahota

 

What I did (that made the difference)
  1. Uncover what’s really going on
  2. Share observations in a loving and caring way
  3. Help people choose their own reality and destiny

Related posts:

  1. The Business Case for an Authentic Workplace People are messy: they have personalities and emotions. In this...

Related posts brought to you by Yet Another Related Posts Plugin.

Categories: Blogs

The Good, The Bad and the Ugly of Scrum: Or Telling The Emperor He Has No Clothes

NetObjectives - Sat, 07/26/2014 - 22:28
I am about to head off to the Agile Conference in Orlando.  At these times I always think about the state of Agile and am usually disappointed when I think about what is possible and what actually is present.  Oh, I don’t mean “if only the industry would do what works” kind of thoughts, I’m more thinking “if only consultants would recognize what works and what doesn’t.”  I just started working...

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

LAST (Lean Agile Systems Thinking) 2014 Conference

Agile World - Venkatesh Krishnamurthy - Sat, 07/26/2014 - 19:26

image Last week I had the pleasure of speaking  at the LAST 2014 (Lean Agile Systems Thinking) conference. This is my second consecutive year of having opportunity to speak at this popular Melbournian event.I  have seen this event growing year after year. First year, we had 150 attendees, the second year 350 and third year is even more successful with 450 people. The event is highly affordable and run by the Melbourne community.  Some call this conference as  “Meet up on Steroids”. 

The two passionate people who are successfully managing this event are Craig Brown  and Ed Wong.  Organizing such a large scale event managing speakers, schedule, events and sponsors is not a simple thing. The event was such a smooth one, didn’t realize that the day had already passed.

This is a classic example of power of passion and network in the community.  You don’t need many people to make a positive difference to the society, you just need one or two passionate givers.

The session was organized by  TABAR 

I spoke about  10 Irrefutable laws of Agile Coaching.  The presentation slides are available on Slideshare as well. Feel free to download/share.  

My intent for sharing these ideas was to encourage Agile coaches to think beyond  Scrum, Lean, XP, etc.   Agile coaching involves a broader systems knowledge to succeed.

More details about my session:  Agile coaching is one of sought after skills in the IT industry and many experienced coaches are doing extremely well. However some change agents are struggling to make an impact, not because, they don't know Agile but because, they don't know some ground rules dealing with the coaching teams and leaders.

Whether you are a novice or an experienced coach, there are irrefutable laws governing Agile coaches. Based on my own personal experiences coaching teams/leaders since the last several years, I have come to realize the 10 secrets. Irrespective of where you are in the journey as an Agile coach, practicing these 10 laws will help you to become a successful Agile coach. These handy rules can help you anywhere in Agile coaching journey.

Categories: Blogs

Fearless Speaking

J.D. Meier's Blog - Sat, 07/26/2014 - 18:58

“Do one thing every day that scares you.” ― Eleanor Roosevelt

I did a deep dive book review.

This time, I reviewed Fearless Speaking.

The book is more than meets the eye.

It’s actually a wealth of personal development skills at your fingertips and it’s a powerful way to grow your personal leadership skills.

In fact, there are almost fifty exercises throughout the book.

Here’s an example of one of the techniques …

Spotlight Technique #1

When you’re overly nervous and anxious as a public speaker, you place yourself in a ‘third degree’ spotlight.  That’s the name for the harsh bright light police detectives use in days gone by to ‘sweat’ a suspect and elicit a confession.  An interrogation room was always otherwise dimly lit, so the source of light trained on the person (who was usually forced to sit in a hard straight backed chair) was unrelenting.

This spotlight is always harsh, hot, and uncomfortable – and the truth is, you voluntarily train it on yourself by believing your audience is unforgiving.  The larger the audience, the more likely you believe that to be true.

So here’s a technique to get out from under this hot spotlight that you’re imagining so vividly turn it around! Visualize swiveling the spotlight so it’s aimed at your audience instead of you.  After all, aren’t you supposed to illuminate your listeners? You don’t want to leave them in the dark, do you?

There’s no doubt that it’s cooler and much more comfortable when you’re out under that harsh light.  The added benefit is that now the light is shining on your listeners – without question the most important people in the room or auditorium!

I like that there are so many exercises and techniques to choose from.   Many of them don’t fit my style, but there were several that exposed me to new ways of thinking and new ideas to try.

And what’s especially great is knowing that these exercise come from professional actors and speakers – it’s like an insider’s guide at your fingertips.

My book review on Fearless Speaking includes a list of all the exercises, the chapters at a glance, key features from the book, and a few of my favorite highlights from the book (sort of like a movie trailer for the book.)

You Might Also Like

7 Habits of Highly Effective People at a Glance

347 Personal Effectiveness Articles to Help You Change Your Game

Effectiveness Blog Post Roundup

Categories: Blogs

An Open Letter to Executives Leading Agile Transformations

Agile Management Blog - VersionOne - Sat, 07/26/2014 - 17:00

Dear Executive,

Let me congratulate you on your decision to introduce agile methods within your organization. It is a wise decision that holds incredible potential for your employees, your company, and especially your customers. If you are just beginning your improvement, or are yet to begin, the journey upon which you are about to embark is one that will be well worth the effort. And it will take effort—long, arduous, and at times frustrating effort.

Although Machiavellians do exist, my experience is that they are exceedingly rare.  In general, people are good, honest, and hard-working and really want to do the right thing. We hold a desire to do our jobs well, be recognized for it, and make a difference in the world by being part of something larger than ourselves; to have a purpose at work, if you will. To this end, we will do what is necessary to get our work done in the manner that our environment best supports. Put more simply, we will take the path of least resistance and complexity. Your move toward agility may be more challenging than necessary if you don’t keep this in mind while traversing your path toward improvement.

Rather than simply introducing and mandating agile methods such as ScrumeXtreme Programming (XP), and/or Kanban, create an organizational environment where agility is the path of least resistance for your employees and colleagues to get their work done. Here is a ten-step plan of action to help you create that environment within your organization.

  1. Stop referring to the change as organizational and/or agile transformation. We’ve all heard and understand the cliché that “change is the only constant.” Using phrases like agile transformation can shoot fear of the unknown into the psyche of everyone as it screams massive change. A less scary word is improvement. We all like to improve. Start talking about improving delivery, increasing customer engagement, and enhancing responsiveness to new challenges.
  2. Restructure your organization to reduce emphasis on functional specialization.One of the factors strongly contributing to the slow responsiveness of waterfall is the typical hand-off of work as it passes from the hands of one functional group to another—Business Analysts for requirements to Architects for design, to Developers for build, etc. Create teams that are cross-functional and require little to no hand-off of work. If so desired, create Centers of Excellence (CoE) organized around professional career ladders but remove reporting ties to any functional manager in the CoE.
  3. Start demonstrating the behavior you desire in your organization. One of the most powerful ways to build momentum is to first change yourself and your behavior. You really can’t force change within others, but you can inspire it. It’s amazing the change you’ll see in others when you first seek to change yourself. Actively seek ways you can serve the teams within your organization. With genuine curiuosity, caring, and empathy ask them what gives them headaches in their jobs. Be the aspirin for these headaches and remove the obstacles that are getting in their way. You might also consider working cross-functionally as a leadership team. Break down functional silos by creating teams that consist of representatives from many departments such as sales, marketing, IT, support, etc. The gears in any machine only work if cogs make contact and work collectively.
  4. For technology projects, refuse to move forward on any project without business representation and team involvement. Be uncompromising about beginning any project that does not have business representation. I was recently asked what I thought was the one thing that, if it did not exist, you could not consider yourself to be agile. This is that one thing—business involvement. If it’s not important enough to warrant business involvement, it’s not important enough to work on. Thank you, Samar Elatta, for this reminder because it’s so obvious it can easily be overlooked.
  5. Completely drop discussions of “resource allocation” and speak only of “team availability”. Agile is a team sport. The focus needs to shift from individuals to teams. Instead of identifying individuals within a functional specialty and percentage of availability to do work seek out only complete teams with availability. Also, don’t begin work with incomplete teams. Have all of the requisite skill sets available so you can avoid slowing them down with the burden that’s created to bring a new team member up to speed on the project.
  6. Increase your delivery cadence. The ideal situation is to be able to deliver at any time (or all the time, as in continuous). Take incremental steps toward this goal by reducing the delivery window by at least half. If you’re on a semi-annual (6-month) delivery cycle reduce it to quarterly. If it’s annual, reduce it to semi-annual; quarterly, release every six weeks. This will automatically require teams to focus on smaller increments of work instead of looking at very long horizon delivery windows that only serve to increase estimating complexity and uncertainty about scope of delivery.
  7. Give high praise for “complete” features only. The only features that provide customer value are those that are complete. Almost done features may have future value potential but they have zero value right now. Consider work either done or not done. There is no credit for work that is not 100% complete. Define expectations very clearly for what is meant by “complete”.
  8. Recognize entire teams. The best way to support teamwork is to value and recognize teamwork, especially in a public setting. Praise entire teams and avoid the temptation to call out individuals on the team that did an excellent job. While it’s true that some of them may well have went above and beyond, it’s dangerous to the cohesiveness of the team if you praise an individual. If you must mention names, mention the names of all individual members of the team. Only the team (those on the frontline of value delivery) has the credibility to recognize individual team members for their efforts.
  9. Don’t mandate a methodology at the team level. Rather than requiring teams to do Scrum, or any other methodology framework, put the ingredients in place for agility such as those described in points 1-8 above, provide and demonstrate your personal support and commitment to the removal of organizational obstacles and dysfunction, and stand out of the way. These people are professionals, they are smart, and are very capable. If not, why are they working in your organization? They will do what’s required to get the results expected of them, sometimes regardless of whether those results are even realistic. This is autonomy and is one of the incubators of the only form of motivation that is effective, intrinsic.
  10. Invest in your workforce and your teams and they will invest in you. I do not tolerate tales of woe about organizations experiencing a lack of worker loyalty when those same organizations refuse to invest in their workforce. When times get tough and the C-suite is getting pressure to show near-term stock price growth, drastic measures are taken to reduce costs. Unfortunately, these short-term measures such as workforce reductions, slashing benefits, and cutting investment in training usually have a negative long-term effect. Make decisions that will positively impact the long-term value of both your stock price and your organization (boths its viability and people). If you’ve created an unsustainable cost structure that requires drastic measures, then you obviously need to take some drastic measures. If you and your management team created it, admit it because your people probably already know it. They have great “BS” meters and will see right through any attempt you or your leadership team make at masking it. Demonstrating humanity through vulnerability and admitting personal fault may feel terrible but it will increase your credibility in the eyes of your constituents by orders of magnitude. If you create an environment that inspires workers to give their all, run a company that gives to the community, and demonstrates that it values its workforce by investing in them, you and your organization will have a much greater chance of competing in the marketplace for a long time to come.

I opened this letter by expressing my belief that people are generally good, honest, and want to do the right thing. I close this letter by restating that this belief I hold has only been reinforced through my personal interaction with a diverse group of colleagues throughout many organizations spanning a long career. I would like to affirm that this belief also extends to you, the organizational leader. I believe that you genuinely want to do the right thing, to contribute to something larger than yourself, and to support those around you to improve the quality of life for each of us.

With high confidence in your ability, personal desire, and integrity I urge you to create an environment within your organization that inspires those around you and that enables agility. The future of your organization is depending on it.

Categories: Companies

R: ggplot – Plotting back to back charts using facet_wrap

Mark Needham - Fri, 07/25/2014 - 23:57

Earlier in the week I showed a way to plot back to back charts using R’s ggplot library but looking back on the code it felt like it was a bit hacky to ‘glue’ two charts together using a grid.

I wanted to find a better way.

To recap, I came up with the following charts showing the RSVPs to Neo4j London meetup events using this code:

2014 07 20 17 42 40

The first thing we need to do to simplify chart generation is to return ‘yes’ and ‘no’ responses in the same cypher query, like so:

timestampToDate <- function(x) as.POSIXct(x / 1000, origin="1970-01-01", tz = "GMT")
 
query = "MATCH (e:Event)<-[:TO]-(response {response: 'yes'})
         WITH e, COLLECT(response) AS yeses
         MATCH (e)<-[:TO]-(response {response: 'no'})<-[:NEXT]-()
         WITH e, COLLECT(response) + yeses AS responses
         UNWIND responses AS response
         RETURN response.time AS time, e.time + e.utc_offset AS eventTime, response.response AS response"
allRSVPs = cypher(graph, query)
allRSVPs$time = timestampToDate(allRSVPs$time)
allRSVPs$eventTime = timestampToDate(allRSVPs$eventTime)
allRSVPs$difference = as.numeric(allRSVPs$eventTime - allRSVPs$time, units="days")

The query is a bit because we want to capture the ‘no’ responses when they initially said yes which is why we check for a ‘NEXT’ relationship when looking for the negative responses.

Let’s inspect allRSVPs:

> allRSVPs[1:10,]
                  time           eventTime response difference
1  2014-06-13 21:49:20 2014-07-22 18:30:00       no   38.86157
2  2014-07-02 22:24:06 2014-07-22 18:30:00      yes   19.83743
3  2014-05-23 23:46:02 2014-07-22 18:30:00      yes   59.78053
4  2014-06-23 21:07:11 2014-07-22 18:30:00      yes   28.89084
5  2014-06-06 15:09:29 2014-07-22 18:30:00      yes   46.13925
6  2014-05-31 13:03:09 2014-07-22 18:30:00      yes   52.22698
7  2014-05-23 23:46:02 2014-07-22 18:30:00      yes   59.78053
8  2014-07-02 12:28:22 2014-07-22 18:30:00      yes   20.25113
9  2014-06-30 23:44:39 2014-07-22 18:30:00      yes   21.78149
10 2014-06-06 15:35:53 2014-07-22 18:30:00      yes   46.12091

We’ve returned the actual response with each row so that we can distinguish between responses. It will also come in useful for pivoting our single chart later on.

The next step is to get ggplot to generate our side by side charts. I started off by plotting both types of response on the same chart:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  geom_bar(binwidth=1)

2014 07 25 22 14 28

This one stacks the ‘yes’ and ‘no’ responses on top of each other which isn’t what we want as it’s difficult to compare the two.

What we need is the facet_wrap function which allows us to generate multiple charts grouped by key. We’ll group by ‘response’:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  geom_bar(binwidth=1) + 
  facet_wrap(~ response, nrow=2, ncol=1)

2014 07 25 22 34 46

The only thing we’re missing now is the red and green colours which is where the scale_fill_manual function comes in handy:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  scale_fill_manual(values=c("#FF0000", "#00FF00")) + 
  geom_bar(binwidth=1) +
  facet_wrap(~ response, nrow=2, ncol=1)

2014 07 25 22 39 56

If we want to show the ‘yes’ chart on top we can pass in an extra parameter to facet_wrap to change where it places the highest value:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  scale_fill_manual(values=c("#FF0000", "#00FF00")) + 
  geom_bar(binwidth=1) +
  facet_wrap(~ response, nrow=2, ncol=1, as.table = FALSE)

2014 07 25 22 43 29

We could go one step further and group by response and day. First let’s add a ‘day’ column to our data frame:

allRSVPs$dayOfWeek = format(allRSVPs$eventTime, "%A")

And now let’s plot the charts using both columns:

ggplot(allRSVPs, aes(x = difference, fill=response)) + 
  scale_fill_manual(values=c("#FF0000", "#00FF00")) + 
  geom_bar(binwidth=1) +
  facet_wrap(~ response + dayOfWeek, as.table = FALSE)

2014 07 25 22 49 57

The distribution of dropouts looks fairly similar for all the days – Thursday is just at an order of magnitude below the other days because we haven’t run many events on Thursdays so far.

At a glance it doesn’t appear that so many people sign up for Thursday events on the day or one day before.

One potential hypothesis is that people have things planned for Thursday whereas they decide more last minute what to do on the other days.

We’ll have to run some more events on Thursdays to see whether that trend holds out.

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

Categories: Blogs

Knowledge Sharing


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