Skip to content

Feed aggregator

The Role of Management in SAFe

NetObjectives - 11 hours 34 min ago
I was asked to chime in on a discussion group about the role of Management in SAFe and as I was writing it up I thought it’d come out better as a blog. I believe the role of manager in Agile has been ignored (the Agile Manifesto), vilified (chickens and pigs) and then to the other extreme transformed (they should be leaders).  In my mind, all three of these is not the role of first line...

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

Effective Teams Patterns

Scrum Expert - 13 hours 50 min ago
Some software development teams are orders of magnitude more effective than others, turning around business solutions in days or even hours. Their secret is a combination of smart technology choices,...

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

Managing Manager-less Processes

TV Agile - 14 hours 4 min ago
A new generation of Agile processes are emerging, frequently omitting the role of a dedicated manager. Erik Meijer has termed his flavor as One Hacker Way; my version was originally titled Programmer Anarchy. We explore the reasons for the emergence of these managerless processes, suggesting they are particularly appropriate for solving “fuzzy problems” (Complex problems […]
Categories: Blogs

#TargetprocessTips: Search, WIP Limits, Batch Actions, Workflows, Card Prioritization

TargetProcess - Edge of Chaos Blog - 15 hours 14 min ago

We've started posting regular product tips to our social media accounts. Just search for #TargetprocessTips on Twitter, Facebook, or LinkedIn to see some bite-sized advice on how to get the most of Targetprocess. Here’s what we’ve posted so far:

Search

Placing a ‘+’ before keywords will yield only exact matches in search results. More on search. 

  • The search bar in the the left menu is used to find a specific view or folder. The search bar to the right of this is the global search; it is used to find entities throughout the system.
  • Global search will not yield results for entities in inactive projects.
  • When using global search, you can replace any letter in your keywords with a ‘?’ to include possible misspellings in the results.

Search

WIP Limits

You can set up WIP Limits for both horizontal and vertical lanes on boards by going to view setup → Limits. Read more here. 

  • When a WIP Limit is exceeded, the state column will be visibly highlighted in red.
  • WIP Limits cannot be applied to the first (initial) state of a workflow.

WIP Limits

Timelines

On Timeline views, the global time period selector is found at the top of the view, while the local time selector is displayed at the bottom. If you're unfamiliar with Timelines, you can learn more about them here

Timeline-Global-Selector

More on Timelines:

  • Timelines are one of the 4 main types of views, along with Boards, Lists, and One-by-One views.
  • You can right-click on a point in the Timeline to add planned start and end dates. 
  • Planned dates are shown with a dotted line, actual dates are shown with solid background, and forecasted time is shown with a semi-transparent background.  

 

Card Prioritization

Prioritize cards on Board and List views by holding the 'Shift’ key and dragging selected cards to the desired position. If the system prevents your from applying prioritization, this guide article should explain why.

Card-Prioritization

Working with cards from multiple views:

You can use the Selected Cards Panel to work with cards from multiple views at once.

  • Since sharing this tip, we've released Batch Actions, which allows you to update multiple entities at once. However, please note that you can only apply Batch Actions to cards on a single view at once.   

Selected Cards Panel

 

Workflow customization:

Admins can rename and customize workflows and states by going to Settings → Process Setup. Read more. 

  • Be careful when editing a process that is currently in use. If you remove states which are populated by entities, the entities will be moved to a different state. 

 

process-usage

Categories: Companies

Sprints or a Kanban?

Agile Game Development - 16 hours 44 min ago
There seems to be some confusion that using Sprints or a Kanban is a competition of sorts with "one being better than the other".  Might as well argue whether a hammer is better than a saw.

Sprints are more suitable to complex problems that a cross-discipline team will swarm on to solve.  Complex work has "unknown unknowns" that require experimentation and defy planning and estimation.  The time-box is a limit of time that is established to touch base with the business side and to replan our next move on a complex mechanic.

A Kanban, a way to visualize a lean flow, is used for complicated work.  Complicated work has "known unknowns", like creating levels and characters for a game with established mechanics.  The variations are manageable. It is more predictable and uses hand-offs of work through a flow.

Using Sprints to manage complicated work results in batched work and an artificial division through sprint planning and review. It hides discipline inefficiencies and leads to split stores which create no value individually. Imagine the cost of buying a house if every one was a custom concept home built by a guild of craftspeople.

Using a Kanban to manage complex work results in turbulent flow that either creates inefficiencies and a lack of transparency or artificial deadlines to call things "done" when they really aren't.  Kanban doesn't handle the back-and-forth of exploration very well. This creates debt and can limit the creative potential of a game. It's why we don't use an assembly line to design a new car.

I often see Kanban used for complex work because there is still an "upfront planning" mindset that thinks a new uncertain game mechanic can be broken down into bite-sized discipline centric steps and pushed though the teams. Sprints are abandoned because the developers cannot be trusted to take larger goals and break down the work as they see fit.

Choose the best tool for the work.  Wielding a hammer with great skill to cut long pieces of wood into smaller ones isn't as useful as using a saw.
Categories: Blogs

SAFe 4.5 Goes Live: Top 5 Reasons to Update

Agile Product Owner - 18 hours 48 min ago

Hi Folks,

About 18 months ago, we launched SAFe 4.0, a major upgrade that delivered innovations for Lean software and systems engineering. It represented a major milestone of maturity for the Framework, and has enjoyed widespread popularity, including being named the #1 scaling framework by VersionOne’s State of Agile Report.

That tells us we were on the right track. But digital disruption is driving innovation at speeds we’ve never seen before, so while enterprises have been busy practicing SAFe, we’ve been busy making sure that the Framework continues to keep pace with emerging development and technology trends.

And so, today we are delighted to announce the release of SAFe 4.5! It’s a reflection of field research from hundreds of implementations, feedback from our customers and community, and new advances made in the knowledge pools upon which SAFe is built. As you learn more, we believe you’ll find 4.5 to be leaner, more Agile, and better at fostering faster innovation and learning than any of its predecessors.

SAFe’s name gets a makeover

We like to think of SAFe as a big tent framework that can accommodate any organization, regardless of size or complexity. As you know, SAFe isn’t just about IT, systems, and software. It’s part of a larger solution development picture, and we absolutely want to be sure that message is front and center for our internal and external business partners, as well as the community at large. So we’ve updated its name to reflect this more inclusive theme. The Framework is now known as SAFe for Lean Enterprises.

Top 5 Reasons to Update to SAFe 4.5

SAFe 4.5 delivers advancements in configurability, implementation guidance, and enhanced capabilities for improving the user experience and accelerating time-to-market. Below is a short summary of the primary enhancements to SAFe; for the in-depth view please refer to Whats New in SAFe 4.5.

  1. Additional flexibility with four new configurations: SAFe 4.5 supports the full range of development environments, from the simplest to the most complex. As the needs of the organization grow, SAFe is able to scale to meet those challenges. SAFe now comes with four out-of-box configurations, starting with ‘Essential SAFe,’ the entry point for organizations that want to start realizing the benefits as soon as possible. A click of the mouse will configure ‘Portfolio SAFe,’ adding portfolio-level concerns, including strategy and investment funding, Agile program guidance, and Lean governance to the picture. ‘Large Solution’ SAFe is for those building really big systems that take multiple Agile Release Trains and Suppliers to build. And finally ‘Full SAFe,’ for the larger enterprises that wants to achieve all the benefits of the truly Lean and Agile enterprise.
  2. Faster innovation with the Lean Startup Cycle and Lean UX : The integration of Lean startup practices and Lean UX in SAFe fosters an environment where investments start as a hypothesis in the form of a Minimum Viable Product (MVP), and feedback is introduced as early as possible to test ideas and make decisions more quickly. If the hypothesis plays out, additional features then make their way through the respective backlogs. If not, fast learning allows the business to pivot to a more desirable solution—and quickly.
  3. Accelerated new feature delivery with Scalable DevOps and Continuous Delivery Pipeline: Of course, you can’t likely get the feedback you need if you can’t move all those new ideas into production more quickly. To that end, the centerpiece of SAFe 4.5 is the integration of the Lean ‘hypothesis-build-measure-learn’ cycle with Scalable DevOps and a Continuous Delivery Pipeline. These new SAFe mechanisms enable the organization to continuously define and deliver solution elements to the end user, without large handoffs or excessive operations overhead. The result is a production environment that is able to deliver value more frequently, where hypotheses can be tested against their intended business outcomes, and where the deployed solution has both the flexibility and robustness needed to deliver more innovative solutions, far more quickly. You may well be a big enterprise, but you can innovate, and SAFe 4.5 can help show you how. 
  4. Improved guidance with the SAFe Implementation Roadmap: We can all admit that becoming a SAFe Lean-Agile enterprise is quite a journey, and a significant organizational change. To that end, we’ve provided new guidance in the form of a 12 article series, the ‘SAFe Implementation Roadmap.’ Based on proven organizational change management strategies and extensive field experience, the Roadmap describes the critical moves that an enterprise can take to achieve early wins and sustainable long-term gains with SAFe.
  5. SAFe 4.5 is fully backwards compatible. And finally, here’s some additional good news:  If you are already on a SAFe 4.0 journey, SAFe 4.5 is backwards compatible. All the features in 4.0 that you’ve come to depend on are still in place. You can adopt the advanced practices of SAFe 4.5 at your own pace, and derive the additional benefits without rocking the boat of your current implementation. 

Click here to get the full rundown of the new features.

In addition to the new 4.5 content, all the 4.0 articles have been updated as well, so there is much more to learn, and gain. For those of you who are certified, you’ll find a What’s New in SAFe 4.0 video on the SAFe Community Platform that will help you learn about the new features, and upgrade your certification so that you can support enterprises seeking SAFe 4.5 implementation.

SAFe Version 4.0 Available Through June, 2018

We encourage you to update to SAFe 4.5 to take advantage of the new features, but recognize that there are enterprises that will need the 4.0 version for some time to come. SAFe 4.0 will be supported throughout June, 2018, and remains available at v4.scaledagileframework.com.

Courseware Updates

Three courses from Scaled Agile’s role-based curriculum have been already updated to reflect the new features of SAFe 4.5. They include: Implementing SAFe, Leading SAFe, and SAFe for Teams. The remaining courses will be updated over the coming weeks.

It is our sincere hope that this new version helps you and your enterprise achieve the benefits you all deserve for working so hard at building the world’s biggest, and best, software and systems. 

We owe a special thanks to you, our SAFe community, for all your feedback and support. Your passion for the best SAFe possible has driven us to deliver what we like to think of as the most adaptable—and now configurable—framework in the world.

We do all this simply because ‘better systems make the world a better place.’

Stay SAFe!
—Dean, Richard, Inbar, and the entire team from Scaled Agile

Dean Leffingwell, Creator of SAFe, Chief Methodologist
Richard Knaster, SAFe Fellow and Principal Consultant
Inbar Oren, SAFe Fellow and Principal Consultant

Categories: Blogs

The Simple Leader: Reduce Information Overload

Evolving Excellence - 21 hours 41 min ago

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen


Everybody gets so much information all day long that they lose their common sense.
– Gertrude Stein

Information overload is a big problem in modern society. We only have so much time and mental capacity to process information, and if we are not careful, the abundance can overwhelm us. We need to make it a priority to wisely manage the information-sharing systems at our companies, including email, phone calls, and voicemail.

Emails can be a big productivity killer if not managed properly. How many emails are in your inbox right now? If you’re like most people, you have dozens, perhaps hundreds. I know a couple folks who have over a thousand! What good is that? Having so many emails in your inbox will make you feel overwhelmed just by looking at it. How is that respecting yourself ?

I used to have more than a couple hundred emails in my inbox at any one time. When it got to be too many, I’d re-sort the inbox by sender and mass delete emails from people I considered to be a lower priority than others. Yes, I really did that. I was not exactly showing respect for people, let alone being mindful of the problems it could create for them and the organization.

This changed for me when a few years ago I came across a blog post touting “Inbox: Zero.” My reaction was, really? Zero emails in your inbox? Although I was skeptical, I gave it a try and haven’t looked back since. I can’t remember the last time I had more than ten emails in my inbox, and I try to get to zero by each evening.

To stay near or at Inbox: Zero takes effort and discipline, which needs to turn into habit. These are the steps to do it:

  1. Aggressively unsubscribe from newsletters and promotional emails, unless you are willing to read them within one day. With the ones that remain, move them to a “To Read” folder immediately, or send them there automatically via an email rule.
  2. Aggressively remove yourself from group distribution lists that are not critical.
  3. If you were just cc’d or bcc’d on an email, scan quickly and make every attempt to not reply, then delete. Ask the sender to remove you from the chain if your attention isn’t critical to the matter.
  4. Add (or decline) invitations to your calendar immediately.
    Be aggressive about declining if you don’t believe the meeting adds value—remember the Just Say No section above.
  5. Try to take action (or respond) to an email immediately whenever possible. Otherwise, move it to a “To-Do” folder. I’ve now become good enough at this that my inbox is my residual to-do folder, generally with less than five tasks to be completed. Many people say this is the worst use for an inbox, but with so few emails it works well.

I can’t describe how liberating this process is. Now, I can give far better attention to the few remaining emails I have and generate more thoughtful and focused responses while respecting the senders and their issues.

Beyond cleaning up your own inbox, you can also help create a better email culture within your organization. First, be very judicious about who is copied on emails, and insist others respect your time as well. An “FYI,” if truly needed in the first place, does not need to be sent to a broad audience—that’s generally more a “CYA” (cover your you-know-what). Second, insist that any desired action be very clearly stated in an email, right at the top. Third, be very concise with original and reply emails. I had a big problem with this, and was known as the king of the long- winded email. I continue to struggle with being too wordy, and have a goal to try to keep emails to three sentences or less.

There are other aspects to email management that help increase your productivity. For example, I try to only check email four times a day, keeping in line with the pomodoro method I described earlier. I hope to reduce that to three times next year. I turned off auto-checking on my phone so I don’t get disturbed with each new email. I also aggressively clear out old saved emails. They may not technically cost anything, and they are searchable history, but they still seem like clutter. I am now actually very close to not only Inbox: Zero, but also Mailbox: Zero!

While email is a known productivity killer, phone and voicemail can also create information overload, if not managed properly. I have never been a fan of using the phone, even though I know it is often a more effective and immediate communication tool than email. I prefer to receive an email so I can properly contemplate and formulate a response. Many organizations, such as Coca-Cola, are turning off their voicemail systems to push people to use email or live phone conversations.

Because of this, and because people know I’m not very good at responding to phone calls, I more regularly use voicemails. (If I did, I’d probably manage very similarly to my email inbox: aggressively filter, and respond immediately.) One thing about the voicemail system that I do love is that any incoming voicemails are also sent to my email inbox. There’s even a service that will auto- transcribe them into the email, so I don’t have to listen to the audio (plus, they are searchable). I know several people that like sending audio messages via email, but in my opinion, they are wasteful for the receiver, as they cannot be quickly scanned and searched. My friend Paul Akers uses them very effectively, but I know others that take two minutes to convey ten seconds of information—which isn’t respecting my time.

Regardless of how you accomplish it, reducing your information overload is very important if you want to be an effective leader. By taking steps to slim down the amount of information that reaches you, you will be able to be more effective with the tasks that truly need your time and attention.

Categories: Blogs

UnBoxing: Open Space Agility workshop

Agile Complexification Inverter - Wed, 06/21/2017 - 04:06
I'm taking Mezick's introduction course to OpenSpace Agility - thought I'd write a bit about what I'm learning.


Day One:
Beginning concepts - leaders have a duty to set direction and name constraints; yet stay away from telling how to achieve the goals.  Executives commits to holding first OpenSpace and Acting upon the proceedings.  And holding a second OpenSpace after a time box (100 days).

A constraining forces in OSA will be the Agile Manifesto, actions and experiments should be judged by this definition and if seen to support it, be considered good.

Another foundational concept of OSA - Self Management - defined as the behavior of a group to know and practice their decision making process (whatever that may be).  A good test is to ask 5 people how their group makes decisions - then count the number of answers - one general description of their decision making apparatus points strongly toward a self-managing team.

Q:  Many agilist are searching for a scaling framework.  If the foundations of agile mindset shift is a willingness to engage in dialogue about possibilities; how does one scale willingness?  Dan pointed to UX designer Micah Zimring candidly discusses his experience of the OpenSpace Agility process, including his initial skepticism going in. (Note: When you hear the the word ‘churn’ used in this interview, it means ‘lack of decision-making’ or ‘indecision’).

Paraphrasing Dan:  'Most Impediments come from:  People making decisions they do not have authority to make e.g. boundary issues with authority & decisions.'

 Harold highly recommended book:  Fierce Conversations by Susan Scott (better than Crucial Conversations - you say potato, I say pootato, let's check it out.)

Day Two:
There was a interesting conversation happening on the pre-meeting video conference... people engaged and communicating on a true personal level (acting with trust).  This is quite unusual for so many tech video conferences, regardless of team size, team maturity level, group dynamics.  I felt as if I'd entered an old familiar bar where everyone knew my name - Norm!

We might return to this concept... later...

So my notes say we might have started with a bit of a lesson on the distinction between some points on the influence spectrum.  After all many Agile "coaches" attempt to influence other people, many times they have great impact for the good (well at least that's how I get to sleep at night).  I may have ruined this one guy's whole sleep over... he joined our little band of developers in Seattle and got along well, we learned to develop working tested software, and to the direction of a great PO.  She had the vision to lead us on a journey - there was some unknown territory along the way - and we discovered the reasons for some weird missions.  Later this guy wrote on a discussion thread about the woes of the good old days - that he'd rather not work on Agile projects any more, because he knows from experience what it can be, what it should be, ... but the project are not that.  It's lipstick on a pig.  He'd rather do waterfall projects.  Because coding to the spec is easy, no work at all really.  However playing the in-between game is hell.

Oh - sorry - that crap just jumped out of my fingers... we were talking about influence - all the way down the slippery slope to manipulation and into coercion.  Now I can not define these term - now after two beers ... and it's just going to get worse as I type and imbibe.  So look it up your self if you don't have a good feeling of the continuum we are discussion.  Do you agree these are on the same dimension?

When does one cross the invisible line from influence to manipulation?  Does it matter... if the ends justify the means?  Dan suggested a way to view manipulation - I'd never heard it explained so well.  I've always considered manipulation as influence in the eyes of the influencer, while being manipulation in the eye of the beholder.  Dan defined manipulation as something you realized happened four hours ago.

What's this got to do with OSA?  Turns out it is a foundational principle of OpenSpace.  The aspect of having freedom and agency to make a decision to participate.  Show of hands - who has been informed by the leaders that they were going to now start practicing this Scrum process, and these coaches were here to help you?  All the hands go up.  Who has been invited to be part of an Agile Transformation?  Two hands only.  Which set of people have been influenced?  Which set have been manipulated?  How does this effect the long term commitment to a "transformation"?

Topic Jump to Meetings - what is the generic structure of a meeting:

  • Goal
  • Rules
  • Progress
  • Participation

Going into detail on these...  but let's just focus upon Progress - how's it measured?  Maybe in most meeting by the clock hands.  Sometimes by agenda items checked off.   Are those items classified into one of a few groups:  discussion, decision, information dissemination, a waste of time.

Participation - is your meeting an Opt-In meeting or an attendance required (with unknown consequences to be determined later by the boss) meeting?  Perhaps making this explicit would be helpful in an organization of more than 5 people.  At the heart of OSA - the invitation (Opt-In) format of the events.

So how does a meeting differ from a Game?  Is there any real difference?  Fun... oh yes!  Why is fun not an emergent outcome of meetings?  Games have this very same structure.

Games and meetings have these aspects as well as structure:

  • Control
  • Progress
  • Belonging

One big difference in games and poorly held meetings is the visual depiction of progress.  In beginner games (Candy Land) the board is the indicator of progress.  It takes very little synthesis to determine who is progressing well in the game.  Chess is quite different.  How are your meetings progressing?  What visual indicator of progress do you include for the people?  Do they become motivated or demotivated by seeing progress made toward a goal?

Why are most games perfectly well run with player participation and no umpire or referee?  Is it the well understood mental model of the rules and proper behavior on the field of play?  What would happen if meetings had these rules?  Do they have rules?  Where's your meeting rule book?

Topic transition to Leadership concerns for OSA.

Sponsor understanding their role and what is about to happen (maybe they feel out of control).
 - development of theme (together, maybe a group)
 - invitation development (come finish the story with us)
Sponsor must communicate:
 - explore the theme & contribute to proceeding (artifact)
 - suspend disbelief for the duration of experiment (100 day trial)
 - invited to the post-experiment Open Space (in 100 days)

Book:  Leader's Guide to Store telling - Steve Denning

Leaders are constantly signaling - ever micro expression gets a mean assigned by followers constantly watching - no rest for the leader - never off stage, the mic is alway HOT.

Story telling is a signaling event with a bull horn.

Book:  https://mitpress.mit.edu/books/honest-signals by Alex Pentland - MIT

Emergent Leadership is like musical chairs.  People change their minds during the game; they may be motivated to move quickly to acquire a seat (at the table), to contribute to the outcome of the story we write to become our future selves.  Open Space encourages people to get a chair.

OpenSpace is a game about authorizing and authority - who has it, who is giving it, who is receding it, etc.  It is played out in a high frequency feedback space of face to face - full body contact - interactive group dynamic.  It is full of potential energy - release it.

Open Space is an Authorizing Function over the time domain of the event.

People authorize others to contribute to the shared understanding, by giving their time and attention to the speaker.  Because they are also free to seek more value if they deem the speakers value lower than opportunity cost.

Day Three:

We started the lesson with the topic of Leadership Prep - the admonishment was to "eat our own dog food" - to open space for the leader to learn about OSA to experiment with safe to fail experiments, to inspect the results and adapt to the needs of the leaders to grow in their understanding of the Open Space.  Search softly for the leader's maximum skin they will put into the game,  cut that in half and practice.  It is this experience (safe to fail) that will lead to understanding - it may be the only way for mere mortals to catch a glimpse of the philosopher's stone inside of the Open Space onion skin of powerful technology.

At some point Harold explained the inside joke of the term Technology in OST... perhaps it's useful in the simplicity of it's inverse, in it's sarcastic usage...  OpenSpace Technology requires the very first and hardest to understand technology that humanoids developed - language skills.

Warning:  Do NOT lead with an unacceptable invitation.  This was Dan's advice, and other's echoed it.  The advice seemed to come from a deep desire to short cut our journey toward successful engagements with clients.  With an action step of starting small, almost imperceivable - don't mention OSA at all - just encourage the leader to make a meeting optional.  A true Opt-In event, with the power of invitation and no repercussion for checking out.  See what the leaders can discover in the behaviors of the people - are they following - are they happily engaged - are they curious - who's participating - who's willing and able to change behaviors?

Another experiment (a few steps up the ladder) - Dan calls it an "A1" meeting.

Look up. B. J. Fogg - Persuasion Lab - I can't remember why - guess I wasn't persuaded.

We spent a bit of time discussing and practicing non-verbale signaling.  A suggested resource: The nonVerbal Dictionary.  Do you read body language?  If not you may be well toward one side of the autism spectrum.  Most everyone does read body language quite well, we've been doing it since very early - I think I heard a story that infants can read facial patterns.

Look into Powerpoint karaoke - a great team game.

Topic of Organizational Learning (time to get your Senge on).

What impedes org learning - fear. When a human is afraid the Neo-cortext is not being engaged, and the monkey mind is getting all the blood flow, this severally limits learning.

What can we do to counter act the stimulus-response mechanism over which we have little immediate control? Create physiological safety... yeah, but how? Well maybe a lesson for another time - but for sure this is a learning enabler. To check this out - watch small kids on the playground. Playing is learning. When play stops - what happened?

Topic of Informal Authorization. How do we recognize this form of authorization? It's communicated constantly, learn to sense it... it's not on a sign post, or in a sound wave - yet it is all around you. Tune into the signal, learn to amplify it, to dampen it and to withdraw informal authorization. It is a powerful force - recognize who is using this, and who is oblivious.

Review: Invitation has: clear goal, rules or constraints, a way to experience progress toward goal, an opt-in participation.

Challenges (Opt-in homework):

Invitation: What are the most simple invitations (with 4 aspects) that we can generate?

Spark some invitation experiences: Issue 3 or more invitations this week.

Read Sprit by Harrison Owen PDF - search for number of occurrences of "open space" vs "Open Space" investigate usage and content - what was he signaling?

Well expect to be surprised: Harrison Owen showed up on the conference call to share some space with our group.

Harrison Owen - discover/giver of Open Space Technology
Here are some badly paraphrased quotes from Harrison:

I have a suspicion or a conviction that:
  • life is self organizing; so, what is a manager for?
  • self organization does the best job; are we stupid to use management techniques?
"Since the universe has been practicing for 13 billion years on self-organizing principles - its not really about improving self organization; but how do we optimize self-organization to enable people?"

Read his book:  Wave Rider

Peter _____ studying behavioral characteristics with performant systems - they have zero regard for external authority.  From scale of micro <--> cosmic.  This group self-organization principle appears to hold true.  Discipline with respect to self organization phenomena :: forcing people to do something that doesn't work for them ... is counter to system goals in long run.  Distinguish between external / internal discipline :: bad / good.

Example traditional education techniques rely upon discipline - it's a destructive force.  Learning is play - Learning is a self organizational system a phenomena with a virtuous cycle.

Day Four:

Question:  what's up with this core protocol: Check in/Check Out process?
A: it's a subtle little hack - about getting a small agreement to communicate and engage.
One might also find info in Influence books topics.

Question: Harrison Owen spoke of "sitting in the Question" - what's that about?
A: not knowing - be OK in that space.
One might also find solace in Donald Rumsfeld's "There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know."
- hummm... or NOT!

Liminality - participants "stand at the threshold" between their previous way of structuring their identity, time, or community, and a new way, which the ritual establishes.
Learning is CHANGE - it is hard to un-learn :: therefore hard to change.  Many people will make up myths to avoid uncertainty and worry - be very very careful who is allowed to create the myths of your organization.  If the leader's are not telling stories - the vacuum of story telling will be filled - by someone.
From Ritual to Theater - Victor Turner - The Human Seriousness of Play
One may think of OpenSpace as a study in authorization - imagine that one could easily and without malice deAuthorize a colleague that was advocating for a position or path that you disagree with.  In OpenSpace this should be relativity easy - see the Law of Two Feet.
Some Wisdom & Warnings:
The Proceedings - one may think the sponsor will do everything suggested in the proceeding and that the sponsor will be responsible for carrying it out - think again.
Watch out for a sponsor that said YES easily.  (But action show them as meaning NO.)
Learning is fundamentally destabilizing - a sponsor or leadership that needs stability might not be ready for a group of subordinates that are ready to learn (make mistakes and attempt new risky behaviors).
If you are actively coaching the Org or leadership; do NOT facilitate the OpenSpace - pass the authority - it will benefit the organization and in the end, you also.

----post workshop:  I attended a one day "open space" styled conference and saw that I had learned quite a bit in Dan's sessions.  Knowledge is like magic.

See Also:
Ted Talk on the use of texture in architecture and the effects upon people in public spaces.
https://www.ted.com/talks/justin_davidson_why_shiny_glass_towers_are_bad_for_city_life

Check out the OpenSpace Agility site.  From the about page:
OpenSpace Agility (OSA) is a repeatable technique for getting a rapid and lasting Agile adoption. It works with what you are currently doing, and can be added at any time. For executive leaders, OSA is a template that operationalizes the core values of Lean, namely: respect for people, and continuous improvement. For executives who are truly committed to these values, OSA represents a simple, effective and very efficient way forward. With OpenSpace Agility, you can expect:
  • A dramatic reduction in the coaching & training costs of implementing your Agile program
  • A genuine, rapid and lasting Agile transformation
  • A dramatic increase in employee engagement scores
  • A dramatic increase in stakeholder satisfaction and potentially, genuine stakeholder delight
  • Predictable, reliable, repeatable, EVIDENCE-BASED improvement in overall results
OpenSpaceAgility incorporates the power of invitation, Open Space, game mechanics, leadership storytelling and more…so your Agile adoption can actually take root. OSA is based on people, THEN practices. You can use any practice or framework with OSA: Scrum, Kanban, DaD, SAFe, LeSS, and more.
Categories: Blogs

The Digital Platform - resurrection of the Hub Strategy

Agile Complexification Inverter - Wed, 06/21/2017 - 03:17
There's a lot of talk these days in the tech sector about "digital _________" or a "______ Platform" - have you noticed it also?  I find this astonishing, as the world turned digital back in the 1980s along with disco.  And as for platform - well adding the word to shoes was a bad idea back then also.

So what causes this echo from the past?

I don't know - shall we investigate this over the next few months - the dog days of summer 2017?

Summer is a season.  Season are cyclical - they come around again and again.  So this brings us to ponder... When do the days get longer and why?  Most people answer Summer.  And what's the longest day of the year (Northern Hemisphere)?  Right June 20th, the summer solstice.  And so the next few days the daylight is getting less and less - all summer long the days get shorter and shorter.  Almost completely backwards from what we thought we knew.


Do you remember way back in 2001... when Steve Jobs laid out Apples Digital Platform - called the Hub Strategy?
"The Mac," Jobs said, "can become the 'digital hub' of our emerging digital lifestyle, adding tremendous value to our other digital devices.""Jobs laid out a path of PC evolution that defined the early 80s as an initial 'golden age' of computing based on productivity software, which began to wane in the early 90s. A 'second golden age' began in the mid-1990s with the rise of Internet; but it too began to lose its momentum by 2000. Jobs said he believed a third age would focus on a digital lifestyle, driven by an 'explosion of digital devices.'"

-- by Phil Simon The Age of the Platform


Steve Jobs introduces the "Digital Hub... by HiltonRobb


Simon writes "Apple forced this third golden age by developing its platform -- and making it so compelling to use." To see the ecosystem of the computer as a hub of your digital life. They have executed on that vision with the iPod, then the iTunes store, the iPhone and the App store, now the iPad and the iBookStore. Are we following a pattern, is there a cookbook? The leader has a vision, shares the vision with the followers, the followers buy into the vision and together make it a reality. 

The new product adoptions phases are progressing quite nicely. Apple is a master at this process, described by David Pogue in: http://pogue.blogs.nytimes.com/2010/01/27/the-apple-ipad-first-impressions/.


Wildly Successful New Product Launch Phases:
  • Phase 1 feverish speculation and hype (preannouncment)
  • Phase 2 disappointment and bashing (prerelease)
  • Phase 3 attainment anticipation and adoration (post release)

See Also:

Why Tim Cook is Steve Ballmer and Why He Still Has His Job at Apple by Steve Blank"What happens to a company when a visionary CEO is gone? Most often innovation dies and the company coasts for years on momentum and its brand. Rarely does it regain its former glory."

Categories: Blogs

Who’s Afraid of Emergent Design?

Leading Agile - Mike Cottmeyer - Tue, 06/20/2017 - 21:39

A hallmark of lightweight software development methods is the notion of emergent design. The idea is that the design of the solution will emerge little by little as we build up the code in small increments, typically using test-driven development with very short red-green-refactor cycles.

When it goes well, we avoid a number of problems. We won’t create a comprehensive design and write a lot of code that only leads us down a rabbit hole that’s hard to climb back out of. We won’t get carried away with our natural creativity and over-engineer the thing way beyond what our customers want to pay for. We won’t end up with a suboptimal architecture because we invested too much too soon in our initial design ideas.

It’s a simple enough idea in principle. It really isn’t difficult in practice, either; I can vouch for the fact it makes the work considerably less stressful and more enjoyable than the Old Ways of building applications.

And yet…

Have you ever tried to push the north poles of two magnets together? The magnets get close, and then slide apart. Each time they slide apart, it’s in a different direction than the time before.

When working with developers who are unaccustomed to emergent design, I sometimes get the same feeling. They seem to understand the concept, and they seem to be getting really close to doing it, and then it slips away from them.

Why so much difficulty? Well, as the saying goes, the devil is in the details.

Where’s the safety net?

If you’ve always worked from a comprehensive, detailed design specification, then starting to code with anything less than that is going to feel pretty uncomfortable. What if you forget something important? How can you be sure the design that emerges will be any good? Lacking detailed design specifications, how will you know whether a proposed code change will affect other parts of the solution?

It feels like you’re crossing a half-frozen river by leaping from ice floe to ice floe. That design documentation was your safety net for changing the code. Now, what are you supposed to do?

Actually, you do have a safety net, and it’s far more trustworthy than any design document. Remember that we use the technique known as test-driven development for emergent design. Those executable test cases accurately and fully describe the low-level behavior of every unit of code in the solution. They are always up to date with respect to the production code, however little or however much of it there is on any given day. Driving every new feature, every modification, and every bug-fix from tests gives you a high degree of protection from errors.

Nothing is foolproof, of course, and like anything else we do in our work, test-driven development is a learned skill that requires practice. But that’s nothing new for you. After all, you weren’t born knowing all the things you know how to do. You had to learn them. All of them. This is just One More Thing. And it’s easier than most of the other things you’ve learned about software development over the years. (See? I told you it was less stressful!)

Just enough design initially

Developers who are just beginning to learn emergent design often hold a certain misconception at first. They think “emergent design” means “no design at all.” You just open up your favorite editor and start typing. That’s not quite right.

There’s an old mantra that (I think) came from the Feature Driven Development community years ago: Just Enough Design Initially (JEDI). To take an emergent approach to solution design, JEDI is our starting point. There’s a lot of territory between comprehensive, detailed up-front design and no design at all. It’s incumbent on us as professionals to be able to make judgments about where, in all that territory, we should begin any given project. It isn’t always the same spot.

Well, if JEDI means different things in different situations, then how are we expected to learn to make judgments about it? The bad news is there are no hard-and-fast rules. The good news is there are no hard-and-fast rules. We get to use our intelligence, creativity, training, and experience, and we get to collaborate with other smart, creative people, rather than just coding to someone else’s spec. (See? I told you it was more enjoyable!)

Architectural design or application design?

I find it useful to draw a distinction between architectural design and application design. Most of the time, when we write a new application we aren’t simultaneously inventing the architecture that supports it. The architecture is like scaffolding on which applications can hang. Yet, many people think it’s mandatory to begin each project by designing the architecture for the solution.

As long as our application is a new instance of an existing type of thing, we don’t need to begin our work with an architectural design. There’s already an architecture, if not several architectures, relevant to our new application. “Just enough” up-front design is probably not very much.

Sometimes, if we’re lucky, we get to build an entirely new type of thing. There’s no existing architecture on which to hang it. In this case, “just enough” up-front design amounts to more than in the first case…but you still might not do a comprehensive design up front, as there’s value in emerging the architectural design, as well, once you get to a good starting point.

We aren’t necessarily starting completely from scratch when we build an application. There may be reference architectures, design patterns, libraries, code generators, and other resources available to save us time and effort. You don’t need to design an architecture to support a new web app. You can choose from Model 2 or MVC, Hierarchical, and Single-Page architectural patterns. You don’t need to design a responsive web app from scratch; you can choose a web app framework that has responsive design built in already. You don’t need to design an architecture for a mainframe batch process that grinds up sequential files all night. You already know it must comprise a subset of extract, sort/merge, edit, update, and report steps. These are well-known types of things, and once you’ve seen an example or two, you never need to re-design one from whole cloth.

The basic advice here is: Don’t reinvent the wheel.

Your past experience counts as up-front design for your next project

I don’t recall where I first read or heard that saying. I didn’t make it up, but I like it. Your new application isn’t identical to any existing application. After all, if it were, then you wouldn’t need to write it at all. But at the same time, the new application probably isn’t so very different from other work you’ve done in the past.

Do you really need to re-draw all the design diagrams you drew on those past projects? I’ll bet you don’t. You’re just checking a box on a checklist of tasks: “Draw design diagrams.” I’ll bet if you drew those diagrams, you’d never look at them again. After all, you didn’t the last 25 times you drew them, now did you? Come on, ‘fess up!

Don’t do anything stupid on purpose

That’s another one of my favorite old sayings. It’s been common among engineers for decades. Signs hang on the walls of labs bearing those inspiring words. All those software design principles folks like us are always jabbering about can be derived from that single ur-principle: Don’t do anything stupid on purpose.

Sometimes, when developers are first trying to apply the idea of emergent design, they very strictly follow the (intentionally)-incomplete and -lightweight specifications to the letter. That is, they don’t do anything that isn’t explicitly specified.

And that violates the ur-principle. You know your application has to handle exceptions gracefully. You know it has to support logging. You know it (probably) has to support internationalization, accessibility, and a host of other things that most or all applications have to do. Do you really need someone to write that stuff down for you every single time? You know the drill.

So, who’s afraid of emergent design? Not you.

The post Who’s Afraid of Emergent Design? appeared first on LeadingAgile.

Categories: Blogs

Scrum is a Journey

Scrum Expert - Tue, 06/20/2017 - 16:24
Even if the Scrum framework is simple and easy to describe, there are still many cases were organizations fail in adopting Scrum. One of the main reasons is that many companies see the transformation...

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

New Case Study: SAFe helps Fitbit Increase velocity by 33%

Agile Product Owner - Mon, 06/19/2017 - 21:04

SAFe has been a successful story for us. It allowed us to grow our team in a seamless way that integrated cross-functional groups and aligned with the company’s long-term strategy. Fitbit has grown significantly since we adopted SAFe, and we were able to scale the process and still deliver high achievement every PI. My VP calls it the scaffolding that has helped move our team forward.”
Damian Brown, Sr. Director of Program Management Office, Fitbit

Our latest case study comes from the consumer technology market, where the pressure is on to release products ahead of major shopping events such as the year-end holiday season, Valentine’s Day, graduation, and Mother’s and Father’s Days.

At Fitbit, the challenge of meeting those targets had increased along with the company’s growth, and their Scrum efforts were not effectively scaling to meet the needs of the business and their global community of users. But in the past year, Fitbit was able to make major progress on the cadence and velocity of its development:

  • Last year, Fitbit released four new products that were positively received by consumers—a record number for the company
  • Teams now achieve five business goals per PI, on average, compared to three previously
  • Velocity increased 33 percent year over year
  • The company experienced no major impact to their website during the critical high-sales time-frame between Black Friday and the New Year
  • As for visibility, Fitbit achieved a long-term look-ahead on its product roadmap and a short-term execution plan, supporting planning and decision-making for leadership.

How did Fitbit achieve all these milestones? The company deployed SAFe in the fall of 2015. Damian Brown and Brian Hsieh at Fitbit had both seen SAFe successfully deployed at a previous company and believed it could work at Fitbit. After gaining executive buy-in, the company started with 12 Scrum teams for Program Increment planning in San Francisco.

With each PI—now up to 10—Fitbit folded in more teams and more functional business groups, including some not typically part of an Agile transformation: Firmware, Software, Design, Research, Marketing, Customer Support, Data Analytics, and Infrastructure Engineering all participate in PIs. To increase the chance of success, Fitbit trained all those who were leading PI events across multiple office locations.

With the help of SAFe, Fitbit evolved its process. It now has a faster and more flexible flow across the ecosystem, smoother scaling, improved visibility, and greater alignment across all programs.

And with higher cadence and velocity, Fitbit can more readily respond to market needs. For example, when the company noticed an opportunity to add a specific capability to its products, it brought the new feature to market in a very short time with no major bugs in internal and external testing.

Now, as the company plans for next year, it’s working toward funding value streams rather than projects.

Check out the full case study.

Many thanks to Damian Brown, Sr. Director of Program Management Office; and Brian Hsieh, Manager of Program Management Office, for sharing Fitbit’s story.

Stay SAFe,
—Dean

Categories: Blogs

How to Design a LeanKit Board that Encourages Speed

Visualizing what you do now is largely regarded as one of the initial steps in a Kanban or...

The post How to Design a LeanKit Board that Encourages Speed appeared first on Blog | LeanKit.

Categories: Companies

Defining “Scaling” Agile, Part 6: Creating the Agile Organization

Johanna Rothman - Mon, 06/19/2017 - 16:30

We might start to think about agile approaches as a project change. However, if you want to “scale” agile, the entire culture changes. Here is a list of the series and how everything changes the organization’s culture:

All of these “scaling” ideas require change.

Agile organizations become very good at small changes all the time. They are adaptive and resilient. They understand how change works and they embrace it. (Big changes are quite difficult for almost everyone. Small changes tend to be much easier.)

Here is a picture of the Satir change model. We start off in Old Status Quo with some level of performance. Some Foreign Element arrives and we have uneven performance while we are in Chaos, searching for that Transforming Idea. We discover that TI and practice and integrate that idea into our work until we reach a New Status Quo, hopefully at a higher level of performance.

The change model works for each human and for the entire organization. In fact, I don’t see how you can have an agile organization until people become comfortable with small and large changes on a regular basis. This is one of the reasons I say we should take an agile approach to agile. (See Agile is Not a Silver Bullet.)

Do you need to be a fully adaptive and resilient organization? Only you can answer that question. Maybe you start from teams and the project portfolio. Maybe you look for incentives that don’t create optimization “up.” (I need a new word for this! Do you have suggestions for me?? Please comment if so.)

You do not have to have a fully agile organization to recognize benefits at the team and project portfolio levels. Agile is Not for Everyone.

Decide how much change your organization needs to be successful. Practice change, as often as you can. That will help you more than an agile label will.

One last comment: I’m not sure “scaling” is the right way to think about this. For me, the scaling idea still has roots in silo thinking, not flow thinking. That could be just me. (Grin!) I wish I had a better way to explain it.

My ideas of scaling agile are about creating a culture based on our ability to change:

  • How do we treat each other? Do we/can we see each other as an intrinsic part of a whole?
  • What do we discuss? Do we discuss “failures” or learning opportunities?
  • What do we reward? How do we move to rewarding non-silo work? That is, work to deliver products (in either projects or programs) or other work that rewards collaboration and flow efficiency.

I hope you enjoyed this series. Please do comment on any of the posts. I am curious about what you think. I will learn from your comments.

Categories: Blogs

New Case Study: SAFe helps Fitbit Increase velocity by 33%

Agile Product Owner - Mon, 06/19/2017 - 16:04

SAFe has been a successful story for us. It allowed us to grow our team in a seamless way that integrated cross-functional groups and aligned with the company’s long-term strategy. Fitbit has grown significantly since we adopted SAFe, and we were able to scale the process and still deliver high achievement every PI. My VP calls it the scaffolding that has helped move our team forward.”
Damian Brown, Sr. Director of Program Management Office, Fitbit

Our latest case study comes from the consumer technology market, where the pressure is on to release products ahead of major shopping events such as the year-end holiday season, Valentine’s Day, graduation, and Mother’s and Father’s Days.

At Fitbit, the challenge of meeting those targets had increased along with the company’s growth, and their Scrum efforts were not effectively scaling to meet the needs of the business and their global community of users. But in the past year, Fitbit was able to make major progress on the cadence and velocity of its development:

  • Last year, Fitbit released four new products that were positively received by consumers—a record number for the company
  • Teams now achieve five business goals per PI, on average, compared to three previously
  • Velocity increased 33 percent year over year
  • The company experienced no major impact to their website during the critical high-sales time-frame between Black Friday and the New Year
  • As for visibility, Fitbit achieved a long-term look-ahead on its product roadmap and a short-term execution plan, supporting planning and decision-making for leadership.

How did Fitbit achieve all these milestones? The company deployed SAFe in the fall of 2015. Damian Brown and Brian Hsieh at Fitbit had both seen SAFe successfully deployed at a previous company and believed it could work at Fitbit. After gaining executive buy-in, the company started with 12 Scrum teams for Program Increment planning in San Francisco.

With each PI—now up to 10—Fitbit folded in more teams and more functional business groups, including some not typically part of an Agile transformation: Firmware, Software, Design, Research, Marketing, Customer Support, Data Analytics, and Infrastructure Engineering all participate in PIs. To increase the chance of success, Fitbit trained all those who were leading PI events across multiple office locations.

With the help of SAFe, Fitbit evolved its process. It now has a faster and more flexible flow across the ecosystem, smoother scaling, improved visibility, and greater alignment across all programs.

And with higher cadence and velocity, Fitbit can more readily respond to market needs. For example, when the company noticed an opportunity to add a specific capability to its products, it brought the new feature to market in a very short time with no major bugs in internal and external testing.

Now, as the company plans for next year, it’s working toward funding value streams rather than projects.

Check out the full case study.

Many thanks to Damian Brown, Sr. Director of Program Management Office; and Brian Hsieh, Manager of Program Management Office, for sharing Fitbit’s story.

Stay SAFe,
—Dean

Categories: Blogs

The Simple Leader: Envision the Future State

Evolving Excellence - Sun, 06/18/2017 - 10:45

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen


If you don’t know where you are going, you’ll end up someplace else.
– Yogi Berra

So now you have defined your principles, your why? (purpose), and your mission, and you’ve thoroughly analyzed the current state of your organization, process, or even you. It’s time to look into the future. This is exciting as you get to dream and be creative!

Based on your why?, what would the ideal future state of your organization, process, or yourself look like? Think toward the long term, perhaps a very long term. What would happen if there were no constraints? What would your metrics be? What new business segments or technologies should you bring online to grow or to mitigate risk? What does your team and employees look like in terms of function and capability?

You could look at other organizations for ideas, but be very careful with benchmarking. Simply adopting someone else’s best practice usually doesn’t work. Every organization’s context, perspective, goals, capabilities, and values are different.

Another way to look at a potential future state is to consider what perfection would look like. If your goal is perfection, then some other organization’s best practice may seem like a mere stepping stone. Thinking about perfection as a possibility can radically change your perspective. Finally, once again, think about you. Where would you like to be—physically, mentally, spiritually, and emotionally—in ten or more years? Document this future state, just like you did for the current state.

Now compare the current and future state documents. Where are the gaps? What are the priorities of the gaps? Which are the most critical to your survival? Which have the most promise? Which are low hanging fruit that can be bridged quickly? Does the future state still align with your principles, why?, and mission? Do all of the stakeholders agree? After going through this process and answering these questions, you should have a defined future state document, showing prioritized gaps and opportunities.

Categories: Blogs

Friendly Guide to Climate Change (and what you can do about it)

Henrik Kniberg's blog - Fri, 06/16/2017 - 20:17

I’ve spent ALOT of time the past few months trying to understand climate change and global warming, and how to effectively contribute. I’ve dug through 1000-page scientific reports, talked to experts, and basically tried to digest as much information as possible. I was surprised by how little I knew before. I’m convinced that, the more people who really understand the problem, the more effectively we’ll be able to solve it (or at least mitigate it).

So here’s a short animated video summarizing the whole issue. The problem, the consequence, the root cause, the solutions, and what you can do to help. All packaged in a fun and easy-to-digest way, same style as my other videos about Spotify Engineering Culture and Agile Product Ownership. The video is all based on solid scientific references, not speculation or rumours.

Please help spread it as widely as possible! Link to this blog post, or the youtube link: https://youtu.be/3CM_KkDuzGQ

I hope this video will inspire many people to make small changes, and a few people to make big changes. Who knows, maybe the next young Elon Musk is out there somewhere, just waiting for the spark of inspiration

Categories: Blogs

Unless these three things exist, your organization will always struggle to adopt agile.

Leading Agile - Mike Cottmeyer - Fri, 06/16/2017 - 19:05

Backlogs, Teams, and Working Tested Software are the fundamental preconditions that must exist for an organization to be able to do agile well. In agile these three things have very specific meanings. Compromising on the quality of the backlog, the completeness of the team or the definition of working tested software always decreases agility.

Backlogs

Most organizations underestimate the amount of time and energy it takes to create backlogs with the needed level of granularity.

  • User stories written in a consistent format
  • 1-3 days in size
  • Agreement on method of collaboration
Teams

Teams that don’t stay together and aren’t able to get to a definition of done stop believing they can and will never stabilize velocity.

  • 6-8 People
  • Work together side by side
  • Swarm to develop solutions
  • Has the ability to produce what is in the backlog.
Working Tested Software
  • Have to know what done looks like
  • Need to be able to get to done by the end of the sprint.

The post Unless these three things exist, your organization will always struggle to adopt agile. appeared first on LeadingAgile.

Categories: Blogs

Targetprocess v.3.11.5: Inline editing, support for negative numbers in numerical fields, bug fixes

TargetProcess - Edge of Chaos Blog - Fri, 06/16/2017 - 17:43
Inline editing improvements

Two more fields are now available for inline editing in Lists: Owner, and Initial Estimate of Features and Epics.

owner-estimate-inline Negative numbers

Negative numbers are now supported in money fields and numerical Custom Fields.

negativenubers

Enabled searching by folders in the left menu

2k27oss2sf

Fixed Bugs
  • If a conflict occurs with another user while editing a Description, the login and email of the other user will now be displayed in the conflict message.
  • POP/IMAP plugin: a new requester won't be created if an active Targetprocess user with such an email already exists
  • Project quick add enabled from views with a State or Process axis.
  • When a User Story is reassigned to another Team, its related tasks will also move (if they have the same team assignment as the User Story).
  • Fixed: Request terms from a default process will now apply to the Settings menu's 'Request Types'.
  • Fixed 'Filter is incorrect' message if counts with predicates are included into DSL filters. For example: ?Assignments.Count(It.Role is 'Developer')>1
  • Fixed multiple issues with VS2015 Add-In.
  • Fixed hyperlinks and text selection in one-line comments.
  • Fixed: Users that can add cards but do not have edit permissions can no longer assign other users to a card.
  • Fixed markdown editor which decoded HTML in edit mode.
  • Non-admin users with 'add' user permission can now add new users.
  • Fixed: Custom Fields for a user disappeared from System Settings > Custom Fields list after any process soft delete.
  • Fixed an installation error that would occur due to cache folder permissions.
  • Fixed ridiculous error 'We can't see if application is loaded' while sharing a Board.
  • Fixed a case where replies to a requester wouldn't work properly. Requester name will now be correctly displayed in email replies.
  • Fixed a case where exporting to CSV would fail with an exception if any lane was filtered by a collection/count.
  • Fixed image duplication in email notifications if a comment contained two different files with the same name.
  • Fixed follow notifications. Follow Activity widget: prefix <!--markdown--> appeared if a comment was added from the markdown editor.
  • Fixed a complex filter:'?assignedUser.where(it is me) and responsible is me'. This filter helps you to view cards assigned to the logged user which are in the state this user is responsible for.
Categories: Companies

scikit-learn: Random forests – Feature Importance

Mark Needham - Fri, 06/16/2017 - 07:55

As I mentioned in a blog post a couple of weeks ago, I’ve been playing around with the Kaggle House Prices competition and the most recent thing I tried was training a random forest regressor.

Unfortunately, although it gave me better results locally it got a worse score on the unseen data, which I figured meant I’d overfitted the model.

I wasn’t really sure how to work out if that theory was true or not, but by chance I was reading Chris Albon’s blog and found a post where he explains how to inspect the importance of every feature in a random forest. Just what I needed!

Stealing from Chris’ post I wrote the following code to work out the feature importance for my dataset:

Prerequisites
import numpy as np
import pandas as pd

from sklearn.ensemble import RandomForestRegressor
from sklearn.model_selection import train_test_split

# We'll use this library to make the display pretty
from tabulate import tabulate
Load Data
train = pd.read_csv('train.csv')

# the model can only handle numeric values so filter out the rest
data = train.select_dtypes(include=[np.number]).interpolate().dropna()
Split train/test sets
y = train.SalePrice
X = data.drop(["SalePrice", "Id"], axis=1)
X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=42, test_size=.33)
Train model
clf = RandomForestRegressor(n_jobs=2, n_estimators=1000)
model = clf.fit(X_train, y_train)
Feature Importance
headers = ["name", "score"]
values = sorted(zip(X_train.columns, model.feature_importances_), key=lambda x: x[1] * -1)
print(tabulate(values, headers, tablefmt="plain"))
name                 score
OverallQual    0.553829
GrLivArea      0.131
BsmtFinSF1     0.0374779
TotalBsmtSF    0.0372076
1stFlrSF       0.0321814
GarageCars     0.0226189
GarageArea     0.0215719
LotArea        0.0214979
YearBuilt      0.0184556
2ndFlrSF       0.0127248
YearRemodAdd   0.0126581
WoodDeckSF     0.0108077
OpenPorchSF    0.00945239
LotFrontage    0.00873811
TotRmsAbvGrd   0.00803121
GarageYrBlt    0.00760442
BsmtUnfSF      0.00715158
MasVnrArea     0.00680341
ScreenPorch    0.00618797
Fireplaces     0.00521741
OverallCond    0.00487722
MoSold         0.00461165
MSSubClass     0.00458496
BedroomAbvGr   0.00253031
FullBath       0.0024245
YrSold         0.00211638
HalfBath       0.0014954
KitchenAbvGr   0.00140786
BsmtFullBath   0.00137335
BsmtFinSF2     0.00107147
EnclosedPorch  0.000951266
3SsnPorch      0.000501238
PoolArea       0.000261668
LowQualFinSF   0.000241304
BsmtHalfBath   0.000179506
MiscVal        0.000154799

So OverallQual is quite a good predictor but then there’s a steep fall to GrLivArea before things really tail off after WoodDeckSF.

I think this is telling us that a lot of these features aren’t useful at all and can be removed from the model. There are also a bunch of categorical/factor variables that have been stripped out of the model but might be predictive of the house price.

These are the next things I’m going to explore:

  • Make the categorical variables numeric (perhaps by using one hot encoding for some of them)
  • Remove the most predictive features and build a model that only uses the other features

The post scikit-learn: Random forests – Feature Importance appeared first on Mark Needham.

Categories: Blogs

Knowledge Sharing


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