This is the first look at one of our new role-based training classes. This is specifically targeted at project managers and related roles such as service delivery manager, program manager, and anyone with responsibility for delivering projects, product releases and similar batches of packaged creative or knowledge work. This new curriculum is scoped within the Modern Management Framework and will be available in 2-day class format at the Advanced Practitioner level with the LeanKanban University curriculum structure. Project Management with Kanban classes will be available publicly and privately from October 1st 2014 from David J. Anderson & Associates. From November 1st, and Accredited Advanced Kanban Trainer (AAKT) will be able to offer the class through the LeanKanban University certified training program.
I was flipping back over the past year and reflecting on the high-value activities that I’ve seen across various Enterprise customers. I think the high-value activities tend to be some variation of the following:
- Customer interaction (virtual, remote, connect with experts)
- Product innovation and ideation.
- Work from anywhere on any device.
- Comprehensive and cross-boundary collaboration (employees, customers, and partners.)
- Connecting with experts.
- Operational intelligence (predictive analytics, predictive maintenance)
- Cross-sell / up-sell and real-time marketing.
- Development and ALM in the Cloud.
- Protecting information and assets.
- Onboarding and enablement.
At first I was thinking of Porter’s Value Chain (Inbound Logistics, Operations, Outbound Logistics, Marketing & Sales, Services), which do help identify where the action is. Next, I was reviewing how when we drive big changes with a customer, it tends to be around changing the customer experience, or changing the employee experiences, or changing the back-office and systems experiences.
You can probably recognize how the mega-trends (Cloud, Mobile, Social, and Big Data) influence the activities above, as well as some popular trends like Consumerization of IT.High-Value Activities in the Enterprise from the Microsoft “Transforming Our Company” Memo
I also found it helpful to review the original memo from July 11, 2013 titled Transforming Our Company. Below are some of my favorite sections from the memo:
“We will engage enterprise on all sides — investing in more high-value activities for enterprise users to do their jobs; empowering people to be productive independent of their enterprise; and building new and innovative solutions for IT professionals and developers. We will also invest in ways to provide value to businesses for their interactions with their customers, building on our strong Dynamics foundation.
Specifically, we will aim to do the following:
Facilitate adoption of our devices and end-user services in enterprise settings. This means embracing consumerization of IT with the vigor we pursued in the initial adoption of PCs by end users and business in the ’90s. Our family of devices must allow people to be more productive, and for them to easily use our devices for work.
Extend our family of devices and services for enterprise high-value activities. We have unique expertise and capacity in this space.
Information assurance. Going forward this will be an area of critical importance to enterprises. We are their trusted partners in this space, and we must continue to innovate for them against a changing security and compliance landscape.
IT management. With more IT delivered as services from the cloud, the function of IT itself will be reimagined. We are best positioned to build the tools and training for that new breed of IT professional.
Big data insight. Businesses have new and expanded needs and opportunities to generate, store and use their own data and the data of the Web to better serve customers, make better decisions and design better products. As our customers’ online interactions with their customers accelerate, they generate massive amounts of data, with the cloud now offering the processing power to make sense of it. We are well-positioned to reimagine data platforms for the cloud, and help unlock insight from the data.
Customer interaction. Organizations today value most those activities that help them fully understand their customers’ needs and help them interact and communicate with them in more responsive and personalized ways. We are well-positioned to deliver services that will enable our customers to interact as never before — to help them match their prospects to the right products and services, derive the insights so they can successfully engage with them, and even help them find and create brand evangelists.
Software development. Finally, developers will continue to write the apps and sites that power the world, and integrate to solve individual problems and challenges. We will support them with the simplest turnkey way to build apps, sites and cloud services, easy integration with our products, and innovation for projects of every size.”
If you can’t imagine what high-value activities look like, or what business transformation would look like, then have a look at this video:
Nedbank was a brick-and-mortar bank that wanted to go digital and, not just catch up to the Cloud world, but leap frog into the future. According to the video description, “Nedbank initiated a program called the Integrated Channel Strategy, focusing on client centered banking experiences using Microsoft Lync. The client experience is integrated and aligned across all channels and seeks to bring about efficiencies for the bank. Video banking with Microsoft Lync gives Nedbank a competitive advantage.”
The most interesting thing about the video is not just what’s possible, but that’s it’s real and happening.
They set a new bar for the future of digital banking.You Might Also Like
For a long time now, I’ve been brute-force ugly with my error handling in my ExpressJS apps. Basically, just throw the exception after it bubbles back up to the route handler.
This works. If you don’t mind the app completely blowing chunks at this point and dumping itself entirely.
Of course, you could put a global error handler in your code to catch this unhandled exception, and *not* exit the app. But this is probably a bad idea, too. Once an exception is thrown (and not handled by the code that was being called, in the first place), the NodeJS environment is basically in an unknown and potentially bad state.Handle It Properly
Unhandled exceptions should be allowed to crash and exit the app. Therefore, you really want to handle this exception in your callback, properly.
It’s a simple change, but using “return next(err);” instead of “throw err;” allows asynchronous code to raise an exception and still have it caught by the error handling pipeline in your app. Instead of putting the app into an unknown state where everything is potential dead or dangerous, calling “next(err)” tells the Express and Connect frameworks to pass the error along until an error handling middleware of function can properly take care of it.Error Handler Middleware
If you weren’t aware of it, every ExpressJS app comes with an error handler (or two – one for development work, one for non-development work… “production” … by default) in the default app.js file that is generated by the express command line:
This code properly handles an error that was sent up the line using the “return next(err);” style of handling. Instead of putting the app in to an exception state by throwing the error, it is properly handled by the middleware, allowing you to write your own custom code, error logging and rendered view in response to the error ocurring.More On Error Handling
There are potentially a lot more advantages to doing things this way, centered around application design and code architecture. But I’ll leave those for other discussions.
If you want to read more about proper error handling, check out this article on error handling in NodeJS, from Joyent (thanks to Peter Lyons for pointing this one out):
— Peter Lyons (@focusaurus) September 6, 2014
Now if you’ll excuse me for a moment, I’ve got to go clean up some error handling code in my apps.Related Stories
The feel of silence is not the absence of noiseIn other words, although the formal definition of silence is the absence of noise, "silence" as a human experience is something different.
This reminds me of a similar phenomena with religions, for example, nominally Theravada Buddhism emphasises original, formal expression of scripture while nominally Mahayana Buddhism emphasises empirical validation and the experience of Buddhism.
In other words, instead of the formal definition of Buddhism as described in scripture, one might emphasise "Buddhism" as a human experience. The feel of Buddhism is not found in the scripture.
A relatively well-known analogy is that of a finger pointing to the moon. The point is to see and experience the moon, not the finger.
How might this apply to this thing we call Agile? Is the feel of Agile found in the Manifesto?
What is the feel of Agile as opposed to the formal definition? What is the Agile moon versus the Agile finger?
I touched on something similar when exploring Agile doctrine but in this case, let's approach things from the perspective of "feeling".
This is what I think captures the essence of the experience and feel of Agile. My attempt at a better "finger" if you will:
- Empathy and insight created by problem solvers being close to the people and situations that have the problems they're trying to solve.
- A sense of safety and confidence created by breaking down larger problems into smaller steps and validating each step.
- A general feeling of dissatisfaction leading to and reinforced by a habit of continuous improvement.
For the first time, I'm posting our curriculum for the Kanban Coaching Professional Masterclass. This new curriculum is scoped within the Modern Management Framework and takes effect in Masterclasses offered after November 1st 2014.
When trying to find impediments there is a trap that awaits those of us who are outside of or observing the team. Often, when you are observing a team as an outsider, you may think you see patterns of behavior and obvious disfunction. Naturally enough, not being part of the system often gives us a fresh perspective from which to see problems within a team. Often I have found myself able to rattle off a list of issues that I see a team dealing with after observing them for only a few minutes. Some patterns of team disfunction are suspiciously easy to detect. But wait, here comes the trap. So you make a list, maybe write up a few recommendations and share your “gift” with the team. What team wouldn’t appreciate someone kind enough to share a list of all the ways they suck?
It doesn’t matter if you are right (and you probably are at least 50% of the time). Best case, the team thanks you for your honesty. Worst case, they kick you out of their standup and tell you never to come back. In any case, they aren’t very likely to take your suggestions seriously. The thing about impediments is, in order to really own them and take them seriously, they need to be something the team genuinely care about – and most likely they should be the team’s idea. Ownership is important, because often impediments are pretty tough to deal with, so you need to be really committed if you expect to resolve them.
Often, what I think I see are two different lists of impediments: the scrum master, coach or manager’s list, and the team’s list. The scrum master is scratching their head wondering, “How can I get these guys to engage with these impediments?” Meanwhile, the team is thinking, “Do you really want to eliminate an impediment? Fire a scrum master!”
So I guess the lesson here is that often nobody is all that interested in what you think the impediments are. They already know what the impediments are. They’re just waiting for someone to really listen.
Filed under: Agile, Coaching, Scrum, Teams Tagged: Agile, coach, Impediments, Team
Al Shalloway, CEO of Net Objectives, discusses how to apply Lean-Kanban at scale to manage software initiatives more effectively. About this Webinar The essence of Kanban is to manage the workflow of value added activities by limiting how much work is being done. Al uses Lean thinking to extend Kanban to the portfolio, program, and team […]
I’ve just added a high level explanation of the anatomy of the Kanban Canvas to the main Kanban Thinking site (where you can downloade the Canvas). I thought I would also post it here.System
How to assess the systemic problem and who is experiencing it.
At the centre of the Canvas is the system being worked on.
Assuming that the current situation is not perfect, and there is always room for improvement, then understanding the scope of the system helps focus on the biggest opportunities for improvement and avoids “rearranging the deck chairs on the Titanic”. By thinking about the situation as part of a holistic system, and having clarity on the scope of the system, we are more likely to identifying opportunities which improve the whole, rather than making smaller, local improvements, which might worsen the whole.
This leads to the question of what is the scope of the system. Defining the system to be too small, might not lead to any significant improvements. Equally defining the system to be too large, might be like trying to “boil the ocean”.
One way of understanding the system is to look at the people involved, and explore what problems those people are having. Narrative is an extremely useful form of doing this – finding and telling stories about people’s experiences and frustration with their work. In particular, the stories related to the customers and stakeholders will start to identify the boundaries of the system.
One fun way of exploring the system through narrative is by using the Pixar Pitch. This approach makes the final “Because of that…” refer to the current kanban system design, and the “Until Finally…” is left blank to be explored in the Impact section.Impacts
How to assess the fitness criteria in terms of flow, value and potential.
The three arrows coming out of the right of the central System are potential Impacts which might be made. These Impacts encourage a focus on what success or failure could look like, before any changes get made.
Given that in most situations, we are dealing with complex problems, where cause and effect are only apparent with hindsight and past solutions are not necessarily repeatable in the future, then we should not try to define a specific future state to solve the problem. However, that does not mean that we cannot determine the characteristics of the outcomes of solutions so we can assess their fitness criteria, or how fit for purpose a solution is.
Impact is an evaluation of fitness for purpose. A successful solution is one which has positive impact and an unsuccessful solution is what which has negative (or no) impact. Impact can be thought of as direction, as opposed to a point solution being a specific destination.
Having explored the scope of the System through narrative, we can also begin to define Impact in a similar way by asking what stories do we want to hear more of, or less off, in the future. When using the Pixar Pitch technique, imaging impossible good and bad endings to the story brings out exaggerated scenarios which can be compared against by asking whether the System is becoming more or less like the suggested endings. Getting both good and bad endings allows both positive and negative Impact to be easily imagined and identified.
When imagining the future, to create a range of diverse possibilities, the Impacts on Flow, Value and Potential are used to encourage thinking from different perspectives.Interventions
How to assess the evolutionary potential in terms of studying, sharing, stabilising, sensing and searching.
The five arrows going into the left of the System are the potential Interventions that could be made. These Interventions provide a frame for appreciating the intent behind various practices, learning and discovering which ways of working are the right ones for the current situation, and transforming those practices as the system continuously evolves.
Working through the interventions encourages continuous curiosity about which tools and techniques to use, understanding when and why they are appropriate, and ultimately collaboratively, co-creating an initial kanban system as a baseline to begin experimenting and improving.
The interventions used are to Study the context, Share the understanding, Stabilise the work, Sense the capability and Search the alternatives.
"As the e-B3-threadComputing I need to call the GarbageCollector in order to improve my memory management performance with 30%"
WOW ! When I first read a story like that I thought : "Great , this is a product about robots and this user story is about E-VE falling in love with WALL-E". As Pixar created "Toy Story", Agile Software Development invented the T-Story ( as "Technical" , of course ) . Some time after meeting the first T-Story of my life I became confused.... Because there were many of them... in all software products, regardless of the company's business that develops that software.Now, that's interesting, how come all humans in the world need exclusively products about wall-E , E-Ve and their cousins? How that did happen?!
Refactoring the Mindset My little idea is that it happened because organisations and companies treated software developers as "translation automates" of "functional requirements" in programming languages. The outcome of this mindset is a target product that is about automates . And the first version of the product risks high to leave business people speechless on a puzzle question : "How the hell did they build such an absurd product "? Well, business people, they built a robotic product that highly make little sense from an user perspective because we might have treated developers as producers of "abstractions".If we want to build products that make sense for humans, there is one think to refactor : the "automate translation" mindset. And grow a software development culture that acknowledges that software products are stories about real people .
Software Products Are Stories About HumansThe "User" side of "User Story" is the key of a great software. Gojko Adzic says that un-experienced teams create T(ethnical) -stories instead of user stories. I think is more than experience , is a question of mind set. Just shift your mind from the T-Story to a real person next to you that experiences the service you're about to implement and think about how does that feel differently. The mind shift from technical layers and composants to small pieces of code that are meaningful from a user experience perspective is hard. Nevertheless , the only way to build shippable products at the end of each sprint is to stick to this rule : every user story is a new - enhanced- experience for the user. How to do that ? If you like methods, Gojko defined the Hamburger Method . It's my favorite. Beyond the "How to" , though, the secret of succeeding is the way we think about the software protect. Because it's not a collection of code, it tells a story where human users are heroes.This is why I strongly believe software developers are writers of stories co-created together with Product Owners, Business People and whoever needs to hang around. Agile people say teams are more performant when they are collocated. If this is true it is because the fireplace where products stories are told needs to stay vivid. The software code embeds a story. Would you like the story your code tell to be awesome ?
Put makeup on your own pig, make it look as good as you can. Don’t go around finding ugly imaginary pigs to stand it beside.
Warning: This article may contain sarcasm and ranting.
Do you have a good idea about how to express something that those guys said a decade and a half ago? Well, then, just say it. You could even set it in context. Here are two ways to do it. One of them is much better than the other in my opinion.Don’t do this
“Individuals and interactions over processes and tools.” That may have been all they knew way back last century, but today we know a hell of a lot more. The real idea is to make decisions about processes and tools at the right level. Often that level is well above the pay grade of the so-called “team”. (And so on.)Instead, do this
“Individuals and interactions over processes and tools.” Here’s one way I like to work with that Agile Manifesto value. We need many tools in the doing of our work. Wherever possible, I like to let each team select its own tools and process. There is a need for consistency in a few areas, but fewer than you might think. (And so on.)What’s going on?
The first approach tries to set you up as smarter than those other guys. You’re trying to set yourself off from others, by tearing them down. Tearing down the other person doesn’t make you taller: it makes you seem small. Maybe your idea is better. Maybe you are smarter. Let your idea show how smart you are. And why set up opposition for yourself. Some people value those old ideas. Do you really want to start by telling them they’re wrong?
The second approach builds on the good things in the past. Referring to the past that way lets you associate yourself with ideas people respect, and makes your ideas seem to fit in with what people already know and care about. You reduce resistance to what you’re saying, making it easier for people to hear you.Straw Man
I often tweet reminders about the straw man from time to time, referring to this picture, entitled “Idea looking comparatively good next to a straw man.
Keep your straw man. Just tell me what you think. There is no need to quote — or more likely misquote — someone else to make your idea look better to me.Exemplum Docet – or, A Rant Begins Here
OK, that said, I’m going to put down some straw men of my own, entirely made up examples no one really said. No one would say them, I’m sure. They’re just made up examples of what not to do, because I need to rant today.
I hate those guys who push Idea X. They’re just doing it for the money. I’m glad I took the high road.
Yeah, well, intercourse you and your penguin. The people who push IdeaX mostly believe in it at least as much as you believe in … in … what is it you believe in, actually? Are you just here to whine about those other unnamed people? Is the problem really that they’re just doing it for the money, or might it be something closer to home, like regret for your own past pathetic decisions? Get over the past. Tomorrow is a new day.
Are you really satisfied with your life? If so, tell me how you managed it. Or are you jealous of someone else’s life? Keep that to yourself.
Those guys had a good idea back at the beginning of the century but what they said should be updated to what we know now.
See previous advice regarding your aquatic flightless bird. Instead of whingeing about what somebody who isn’t you did years ago, why not come up with an idea or two of your own? And instead of using your critique of those people to launch your wondrous and doubtless fascinating advice, come up with a new name.
Tell me your idea. Maybe you can even find 13 other people to help you create your marvelous new idea. Get it out there. See if it can stand the test of time.
Some people think Stupid Idea A. I teach Smart Idea B. Hahaha on those other guys. I am smarter than they are.
Where are all these fish-reeking black and white flappy creatures coming from? It’s starting to bug me. No one with even minimal credibility ever supported Stupid Idea A. You twisted the words of ten smart and sincere people to create that ridiculous idea, which is held by exactly no people anywhere. You aren’t just trying to make yourself, and your idea look good, by any chance?
Just tell me your smart idea. No need to set it up by surrounding it with stupid ideas that your readers don’t believe anyway.TL;DR
Make your own lawn look good. Stop throwing trash onto mine.
Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.
So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it
Last night we did a talk for SUGSA (the Scrum User Group of South Africa). It was a blast and full of eager learners
We spoke about 2 techniques – one to talk and understand capacity and one to assist with prioritisation. The slides are on slideshare.
If you are keen to read about more of these workshops, please buy our books!
Here is a writeup from the committee: http://sugsa.org.za/2014/09/event-report-product-owners-dealing-with-capacity-and-prioritisation/.
I don’t want to get on a rant here, but…In the Agile community and perhaps in the IT community in general there is a tendency to use the term “Continuous Improvement” to describe some sort of mythical state where teams are constantly evolving toward some state of perfection. At least that’s what I think of when I hear the term. Now I don’t know about you, but I don’t think I’ve ever seen such a creature in the wild (or even anything close to it). Furthermore, I’m concerned that using such terminology sets an unrealistic expectation for performance with our customers and stakeholders.
As an example, I’ll use myself. Right now, despite a host of good intentions on my part, I am not continuously improving. I’m typing – my spelling and grammar are showing no discernible sign of improvement (as I’m quite sure you, dear reader, are all too painfully aware of). Honestly, I’m just not improving right now. In fact, I haven’t done anything to improve my blog writing since the last time I wrote one a week ago…a month ago…6 months ago…
“But Tom don’t be so hard on yourself!” You say, “Just by writing more you are improving your writing skill and the content of the blog.” To this my answer would be, “So just writing more code is improving too?” We all know the answer to that question. So no, the only thing writing does by itself, is make the number of words on the page grow.
In fact, I have a confession to make. Nothing I plan to do in the next 24 hours has anything with improvement. Not even:
- Attending meetings (generally the opposite of improvement)
- Writing status reports (ditto)
- Cleaning the house (status quo – just fighting entropy is not improvement)
- Commuting (status quo)
- Watching TV (gently sliding toward entropic oblivion)
- Sleeping (mandatory, but not improvement, at best it’s re-establishing the status quo)
You see, true improvement is really hard work, therefore I don’t do it very often. I certainly have never been able to do it “continuously”. Hah! What a ridiculous notion that is! Nobody can improve continuously. We all need to take a break. Taking a break is actually necessary in order to improve! So the very term “continuous improvement” is at best misleading and at worst an idiotic notion. It can’t be done! Combining the terms continuous and improvement is like the old joke about the term military intelligence – it just doesn’t exist!
Up to this point I’ve just been ranting about continuous improvement, but in the Agile community we use the “continuous” word everywhere. There’s continuous integration, continuous delivery, and I’m sure there are a few more I haven’t even thought of. Take any one of those continuous activities and look at it closely enough, and guess what? Not much is happening. I’m willing to bet that your continuous integration server isn’t constantly running builds all the time (at least I hope not). I’m sure the average integration server spends a lot of time just waiting for the next build request. I hope by now it is pretty apparent that very few things are really continuous. I think we need a better term to describe these processes. I would propose: Periodic, Frequent, Event-driven or my personal favorite – on demand.
I know, I really do get it – continuous sounds just better. Continuous has an aspirational sort of quality to it which you can’t help but admire. I think that it’s just a little disingenuous to use that term for things that may not even take place for an hour or even a day at a time. If improvement is really continuous in nature, I want to see evidence of improvement taking place as I’m watching, when my back is turned, on weekends, and perhaps even when visiting the bathroom. Is that too high a bar to set? I don’t think so. I make that demand of my lowly alarm clock. I’m not saying improvement doesn’t take place. It happens – for some of us it happens pretty frequently. For others, it happens on demand at the end of the sprint.
Improvement may be a never-ending quest, but it is rarely, if ever, continuous.
Filed under: Agile, Scrum Tagged: Agile, Continuous Improvement, Process
As part of our continuing sneak peak of the new LeanKanban Modern Management Framework, I want to show how we are using it to define and communicate the curriculum for individual training classes. We are now offering a wide range of training classes at different levels. Here we look at the 2-day Kanban Foundation level training...
You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
The Scrum Checklist, For the Agile Scrum Master, Product Owner, Stakeholder and…
Scrum Shortcuts without Cutting Corners: Agile Tactics, … http://t.co/WbPQG1ZLAR
The Scrum Field Guide: Practical Advice for Your First Year (Agile So… http://t.co/m6anhQFzT3
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips… http://t.co/7gdWe7hJYa
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, … http://t.co/QbUIanWZeg
The Power of Scrum, In the Real World, For the Agile Scrum… http://t.co/VIq06iXrHL
Scrum, (Mega Pack), For the Agile Scrum Master, Product Ow… http://t.co/kkgUHslrsI
Scrum Essentials: Agile Software Development and Agile Pro… http://t.co/SUQg4YExVN
How to Become a Scrum Master in 7 Simple Steps (Agile Proj… http://t.co/mrzu1hoipr
The Scrum Checklist, For the Agile Scrum Master, Product O… http://t.co/DTo1bZJQZ5
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-W…
The Power of Scrum, In the Real World, For the Agile Scr… http://t.co/UPPYWasnYT
Scrum, (Mega Pack), For the Agile Scrum Master, Product … http://t.co/uDN3DOX6tM
Scrum Essentials: Agile Software Development and Agile P… http://t.co/eTRG5IMEgI
How to Become a Scrum Master in 7 Simple Steps (Agile Pr… http://t.co/5BFMA3sEMJ
The Scrum Checklist, For the Agile Scrum Master, Product… http://t.co/mpox08osyE
Scrum Shortcuts without Cutting Corners: Agile Tactics, To… http://t.co/Mk69h7axIf
Bacon & Eggs The chicken contributes, But the pig gives his all. I've never been a user of Scrum's Chicken/Pig metaphor. It's a metaphor used by many Scrum coaches and trainers to provide a brief, humorous reminder that the team needs to be free to self-organize in order to accomplish their activities in an efficient and sustainable way. Awesome goal.
Just to be clear where I'm coming from today:
- I get it. A Certified Scrum Master once suggested that I don't understand the metaphor, and offered to elaborate. [I'm actually a little flattered whenever my opinion is interpreted as ignorance.] I'm not expressing ignorance, today, so save your keystrokes.
- My feelings have not been hurt. [It's nice that folks worry about my feelings, too.] Someone once suggested that if I was uncomfortable with this metaphor, I should simply stop using it. [Commonly referred to as "blaming the victim."] I am expressing my opinion, of course, but I'm also conveying the feedback from dozens of behemoth corporations and popular little startups. [Heed my warnings, lest you be visited by three spirits...!]
- It's impolite: A few key people in almost every organization I've coached have expressed their discomfort with folks referring to themselves or other people as farm animals. To do so, even metaphorically, is often considered disrespectful, and unprofessional.
- It's inaccurate: Many people who may not be directly responsible for creation and delivery may still have a critical stake in the success of the team (i.e., "skin in the game"), e.g., the Product Owner. Generalizing the Scrum roles in this way (as a divisive caste system) discourages people from dealing with other people in a genuine way. A coach needs to be careful to avoid subtly encouraging blatant disrespect towards leadership, or subtle disrespect for the team. A coach should be encouraging respect and professionalism at all levels. We're usually there to repair the relationship between makers and leaders. The chicken/pig metaphor does little more (at best) than acknowledge the problem, and frequently (at worst) exacerbates existing bitterness.
- It's limited: To me, the metaphor only make sense with regard to the daily "scrum" or stand-up meeting, and (in some cases, or so I've heard) the retrospective. "Pigs Only! No chickens!" It could be interpreted as discouraging collaboration with leadership.
- It's old: It was Schwaber's clever metaphor about 20 years ago. Using it now would feel dogmatic, uncreative, and clumsy.
And if they all choose Scrum's Pigs and Chickens metaphor, so be it. It is, after all, their restaurant.
Imagine... You're working in swift code and you need to explain something to a co-worker. Easiest would be to just explain it and show the code right. So you grab your trusty editor and type some markdown.
let it = "be awesome"
So now you have a file filled with content:
But it would be better if it looked like:
Well you can and it's super simple, all you need is some Markdown and:
npm install -g swift-playground-builder
After that it's a matter of running:
I read constantly, but I’ve not reported lately on what I’ve been reading. These are things I’ve read, enjoyed, found valuable. I’ll mention some tools and toys as well. I’ll leave out things I hated. Isn’t that nice of me?Non-Fiction
Drive: The Surprising Truth About What Motivates Us, by Daniel Pink, has inspired a chapter in The Nature of Software Development, coming soon. He tells us that people are motivated by Purpose, Autonomy, and Mastery. This rings very true to me, and I hope it does to you.
Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration, by Ed Catmull, tells the story of Pixar and how they maintain creativity in the face of relentless schedules and being part of a big business. I hope never again to be part of a big business, but Catmull’s stories of leadership are inspiring.
Essentialism: The Disciplined Pursuit of Less by Ed McKeown, isn’t yet another book about simplifying your life. Well, it is, I suppose, but his approach to thinking about what really matters is valuable. I’m a sucker for thinking about myself, and if you are as well, you’ll find this book to be quite useful.
The Man Who Knew Too Much: Alan Turing and the Invention of the Computer (Great Discoveries), by David Leavitt, is a very interesting story of Turing, his contributions, and the tragic end he came to. Fortunately, that last bit is mercifully brief and the story is quite interesting. It includes quite a lot about math and code-breaking but you can safely skip over those bits if you find them too heavy. Good story of an important figure in our profession.
The Art Spirit, by Robert Henri, is a collection of writings about art. Henri holds that most anything we do well is art, and that art is the province of any human being. Very enjoyable.
Joy, Inc.: How We Built a Workplace People Love, by Richard Sheridan, is the story of his company, Menlo Associates, and the thinking behind it. Quite idealistic, quite practical. Sheridan has built a very successful company with a focus on Joy. Definitely something to learn here.Fiction
My fiction reading is all over the map. Science fiction, with forays into fantasy and steampunk. Adventure novels, spy novels. Once in a rare while, something like literature. Here’s a small sampling:
The Iron Wyrm Affair, by Lilith Saintcrow, takes place in what seems to be Victorian London in an alternate universe. Emma Bannon is a sorceress in service of the spirit Britannia (and her avatar Queen Victrix), while Archibald Clare, her sometime work partner, is a “mentath”, a master of logic and deduction who rivals the great Holmes. Sounds pretty fluffy but this story and the following ones are strong, a bit dark, and quite enjoyable if you like the steampunk kind of thing. Saintcrow’s novels often please me. These are my faves of hers.
Sniper’s Honor, by Stephen Hunter, is the ninth in his excellent series about Bob Lee Swagger, an aging retired sniper who gets into dangerous adventures, always involving snipers gone bad. The novels usually include a bit of history and are good spy/adventure stories.
Permutation City: A Novel, by Greg Egan, is a hard SF story of people who load their personalities into computers for fun, research, and, ultimately to survive the death of the solar system. I think Bill Tozier (@vaguery) put me onto this one, and I enjoyed it.
Another tip from Tozier was the Bel Dame Apocrypha series by Kameron Hurley, starting with God’s War: Bel Dame Apocrypha Volume 1. Is it set in some kind of a post-apocalyptic desert on Earth? On another planet? In a different universe? Fascinating, and it gets more so as the series goes along. Dark, and I think everyone dies — at least once.
I would be remiss if I didn’t point out the work of Iain M Banks, who recently passed away. His “Culture” series, beginning with Consider Phlebas, is charming, funny, and deep. Truly great hard SF. Worth it for the names of the intelligent ships alone. Very highly recommended.Tools and Toys
I guess I might as well show you some of the toys I’ve recently bought, for fun or profit. You may know that I’m trying to learn to draw, and my theory is that as soon as I get the right equipment, I’ll be able to do it.
I have a fine Derwent pencil wrap for my ten thousand pencils, which come in all colors, textures, and permanence. This Derwent Canvas Carry-All Bag has room for those, my many erasers, and even a sketch book. And I can slip the iPad into it for those days when I can’t just be purely analog. The first one came without the included shoulder strap and Amazon sent me a new one by next day shipping.
Laura Fisher, my webmistress (not as interesting as it sounds) told me about these Staedtler Watercolor Pencils. Since when I draw with Paper(tm), I often use the watercolor brush to color things, I thought I’d try these. You shade as you would with a pencil, then dab on a little water with a brush, and voila. Lots of fun and messy too.
I also have an Parrot AR.Drone 2.0 Quadricopter, which is lots of fun. Parrot’s upcoming Bebop comes with a joystick controller, longer range etc etc. I thought it would be good to practice with joysticks, so I bought Syma X1, the little guy above, as well. So far, I am incredibly good at crashing it.