I often find myself doing random calculations and I used to do so part manually and part using Alfred‘s calculator until Alistair pointed me at Soulver, a desktop/iPhone/iPad app, which is even better.
I thought I’d write some examples of calculations I use it for, partly so I’ll remember the syntax in future!
Calculating how much memory Neo4j memory mapping will take up
800 mb + 2660mb + 6600mb + 9500mb + 40mb in GB = 19.6 GB
How long would it take to cover 20,000 km at 100 km / day?
20,000 km / 100 km/day in months = 6.57097681677241832481 months
How long did an import of some data using the Neo4j shell take?
4550855 ms in minutes = 75.84758333333333333333 minutes
Bit shift 1 by 32 places
1 << 32 = 4,294,967,296
Translating into easier to digest units
32381KB / second in MB per minute = 1,942.86 MB/minute 500,000 / 3 years in per hour = 19.01324310408685857874 per hour^2
How long would it take to process a chunk of data?
100 GB / (32381KB / second in MB per minute) = 51.47051254336390681778 minutes
Hexadecimal to base 10
0x1111 = 4,369 1 + 16 + 16^2 + 16^3 = 4,369
I’m sure there’s much more that you can do that I haven’t figured out yet but even for these simple examples it saves me a bunch of time.
Here are the issues this group thought were important. Many are ‘issues’ in a waterfall model. Not necessarily in priority order. Not necessarily impediments in an Agile model. Some are vague here (stated in few words), but I think they knew what they really meant.
- Management apathy
- Unclear goals
- Too much process
- Changing requirements
- Insufficient people
- Work overloaded
- Large team
- Redundant skillset
- Internal compertition
- Single out individuals
- Late request
- Project cancelled
- Newly formed team
- More layers (different teams)
- Too many scope creeps
- Not enough executive engagement
- Not good leadership
- Delays from vendor
- Not enough knowledge in team to solve issues
- Tasks not properly assigned to team members
- Didn’t allocate enough time for unknowns
- Team was told what / when
- Management and Execs painting a different picture
- Blame / “steamrolling”
- Forced to “report” waterfall way
- No clear product owner
I hate code that looks like this:
Double negatives are so hard to follow in code… it constantly makes me nervous, wondering if I’m getting the logic right. Am I not doing it? Ok if I’m not, not doing it, then do this?
Please, for your sanity and mind, avoid double negative boolean logic like this. Instead, invert this so that it’s simple boolean logic:
There’s no reason to use double negative boolean logic when you can have simple, clean code like this instead. So do us all a favor. Don’t not avoid double negative boolean logic.Related Stories
We are happy to announce the release of the Semantic Logging Application Block (SLAB) v1.1. It has exciting new features that will make developers more productive and that help improve your operational intelligence. I want to highlight three in particular:
- Support for activity tracing
Support for activity IDs for EventSources is available in .NET 4.5.1. This version of SLAB adds support for capturing and storing in all supported sinks the new ActivityId and RelatedActivityId properties from events published by EventSource classes.
- Added new EnableEvents and DisableEvents extension methods to the EventListener to configure event listeners using an event source name rather than an event source instance.
This allows capturing events from sources that are not publicly accessible, such as those generated by the TPL event provider to indicate activity ID transfers when tasks are used.
- Added Elasticsearch sink
A configurable sink to publish log events to Elasticsearch server (1.x). The sink can be used in– or out-of-process, and buffers events when writing them to the Elasticsearch server.
For other features, deployment considerations and known issues, I refer you to the official Release Notes.
I’d like to emphasize the fact that the new Elasticsearch sink feature of this release was largely a community-driven effort. This is the first official release of the block after we started accepting community pull requests. Big thanks to all contributors. With this example of a fruitful collaboration between Microsoft and the developer community, I’d like to encourage other developers to engage with us and help improve SLAB and other p&p deliverables. If interested, our contribution guidelines can be found here.
SLAB1.1 with the corresponding sinks ships under Apache2.0 license through NuGet. These are the package names:
As always, try it, use it, let us know what you think.
Visual.ly InfographicUnderstanding why an organization thinks it needs to change is enlightening. Many times the people at the bottom ranks of the organization have no idea the driving forces that necessitate a change. As a group brainstorm a list of possible reasons for the change.
Dialogue on the difference between change and transition. How long does change take? What is a transition? Bridges Transition Model: Ending - Neutral Zone - New Beginning.
Dialogue on the difference between satisfiers and dissatisfaction in the workplace (Herzberg's Two-Factor theory).
See Gallup's Q12 Employee Engagement survey.
First just capture all the reasons that might be the answer to - Why change?
Typical reasons (if you need to prime the pump - or when the answers slow down - throw one of these out to head in a different direction).
- Current process just doesn’t work
- Decrease time to market for new products
- Cost reductions, improve effeciencies
- Scrum is the methodology of the decade (soup de-jour)
- We’ve tried all the others - maybe this one will catch on
- The boss said so
- Our competator is doing it
- Exponential change rate of market space requires ability to “pivot” into new market spaces with our existing products
- We don’t really know what our customers desire until we deliver it
- Outsourcing is hard so maybe this will fix it
- Our quality is too low - so Scrum will fix it
- Dot Vote - 3 dots each - which is the organization true motivation?
- 5 Whys? - Identify one item and ask WHY until you have a root cause motivation.
Intrinsic vs Extrinsic Motivation
Herzberg's Two Factor Theory
Interesting links on Motivation
First Break ALL the Rules.
Video series on Scrum (short takes)
A Release planning and Scrum simulation - Priates of the Carriballoonian
Project success sliders
Quikie video explains relative vs absolute measures
Dog Grooming - agile estimation technique
Elements of an effective scrum board - checklist
Pick the Metrics to use to evaluate your team
If your Agile and you know it - clap your hands. Prove it - show me the practices that support a claim of agility
Definition of Done & Ready
Intro the concepts of TDD & Refactoring
Create a set of well known plays for the team
Experience the power of prototyping and evolutionary design - Marshmallow challenge & video
Pair programming exercise
What Motivates your Employees
Many people are familiar with process evaluation like The Nokia Test. There are also mash-ups of popular assessments, and I like The Borland Agile Assessment about the best, because it focuses on qualities (We work in an environment of trust and respect), rather than compliance (Single Product Backlog). Jeff Patton wrote an article, Performing a Simple Process Health […]
The post Evaluate Process Qualities, not Process Compliance appeared first on Constantly Changing.
Many time, in the middle of developing a user story, the programmer discovers a question about how it’s intended to work. Or the tester, when looking at the functionality that’s been developed, questions if it’s really supposed to work that way. I once worked with a team that too-often found that, when the programmer picked up the card, there were questions that hadn’t been thought out. The team created a new column on the sprint board, “Needs Analysis,” to the left of “Ready for Development,” for these cards that had been planned without being well understood.
It was that problem that the Three Amigos meeting was invented to address. Rather than wait until a story was in the sprint to fully understand it, stories that were on-deck for the next sprint would be discussed by representatives of the business, the programmers, and the testers to make sure that all the questions were answered before considering the story ready for development. Sure, the occasional question still came up during development, but the epidemic had been stemmed.
Since that time, I’ve found better ways to determine if a story is ready for development. I look for the list of essential examples, or acceptance scenarios, that the completed story will satisfy. These provide a crispness to the understanding of the story that’s hard to achieve any other way.
There are fringe benefits to going to this level of detail. Planning discussions of the story don’t spend a lot of time understanding what the story means. These discussions don’t go round-and-round finding the boundaries of the story. If the scenario isn’t listed, it’s part of another story (or it’s been overlooked). In fact, dividing the scenarios into groups is a simple way to split a story into smaller ones.
Another benefit is that the scenarios can be automated as acceptance tests prior to the development of the functionality. Having a clear picture of the outcome before starting helps keep the development on track, minimizing premature speculation of future needs and maximizing attention to current edge cases that might otherwise be overlooked.
In a development process that uses sprints or timeboxes, you’ve got the whole sprint to get the next sprint’s worth of stories refined prior to planning. If you’re practicing a single-piece pull process, you’ve got the length of time a story spends in the development input queue to do so. Either way, refining the backlog is a necessary overhead activity that should be done a little at a time, all the time.
The goal is to have the work done just-in-time for planning and development. It should be complete enough to avoid stoppages to build more understanding, but not so far in advance that the details get stale. We want our scenarios to take advantage of the most knowledge we can bring to bear. If done too early, we may have to revisit the scenarios to see if we need to alter them according to what we’ve learned since we created them.
More often than creating too many acceptance scenarios too early, I find teams spending this effort too late. It seems a lot of work to go to such detail when we know we’ve got a mountain of work to accomplish.
Developing software correctly is a detail-oriented business. We’re going to have to get to that detail sooner or later. Leaving it until the programmer has a question causes interruptions in development, delays, lost effort, and, sometimes, unwarranted assumptions that give us results we don’t want. Don’t look at the mountain of work. Look at the little bit of work we’ve decided to tackle next. Do a great job on that, and things will go more smoothly.
Here’s a short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog).
This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o)
Part 2 hasn’t been recorded yet. Stay tuned.
Last friday we had the pleasure of having CS students Sofie Lindblom and Anton Arbring as guests visiting the monthly competence day at Omegapoint.
After this visit, Sofie have done me the honour of musing on the theme of our letters by writing an open letter "Dear Senior, Letter to a Senior Programmer".
That post is so full with interesting topics it would take a day just to briefly discuss them. But those topics are also way too important to leave uncommented. So, to do something, let us pick one important thing and discuss it. I pick the topic about "what to learn".
Too much information out there - as always have been
But there is too much information out there to know where to start. I am not stupid, I did very well in all programming courses and is a fast learner. But I feel exhausted by the amount of information available.To start somewhere, let us start with the vast amount of information, technology, frameworks, etc that are out there. Obviously there is no way to take in all of that. If we want to use metaphors, it does not suffice saying "drinking from the fire-hose", it is rather to try to gulp the Nile.
Good part is that the situation is not new. Of course there are more information out there now compared to 15 years ago when I left university. But even then the amount of information available was too much for any individual to comprehend. And the situation is even older. The proverb "so many books, so little time" is not fresh-out-of-the-presses.
For those leaving university today, there will be truckloads of technology you will be using at work that you did not learn in class. But that situation is not new either. When I left university, I had not used a relational database in any single class or lab. Still, most systems (not all), I have worked with professionally have included SQL databases of some sort. Actually, one of my first jobs was to teach a class on the Java database API JDBC. How did I manage?
The obvious solution is to replace "know everything" with "able to comprehend". We cannot know everything beforehand, but we need to be able to understand any technology we come across with just spending a reasonable amount of work.
Killing a meme
There is a meme around in this information age that basically goes "you do not need to know, you need to be able to find information". I want to kill that meme in the context of system development.
The meme might very well be true, with Wikipedia and the rest of the web at our fingertips we will be able to find data like "first historically recorded solar eclipse" (5th of May 1375 BC in Ugarit). Nevertheless true, it is worthless to us as software professionals. Because what we need is not data or information, but understanding.
Deep knowledge feed deep knowledge
Now, this is only my own meandering experience, but I have found it invaluable to know a few things really well. Deep knowledge has interesting side effects. Suddenly you see some pattern apply to a new domain. It seems like no domain of knowledge is an island. Even if facts do not carry across boarders, some structures of thinking and reasoning actually apply.
This is really vague, so let me throw some examples to clarify. When studying law I suddenly found that my studies of formal logic really helped me. I studied negotiation theory and found how it applies to finding a good architecture for a software system. I studied compiler technology and found it helpful when studying linguistics. Through my lifelong studies of math, I see wonderful aspects of beauty in the world every day. (OK, the last is a little bit off topic - but it makes my life richer, and that is worth something)
The strategy I try to apply myself is to study subjects in depth, to the level when I have to think hard about them. The specific knowledge might not be immediately applicable - I will probably not have any specific use of knowing e g how to count the number of ways to paint a cube using several colours. However, thinking hard has probably etched new traces in my brain - and those ways of thinking will probably pop up applicable in a new domain.
To fall back on metaphors again. As software developers we need to dig deep to understand a new technology. To get down to depth we are not very helped by having dug a meter deep over a large area. But if we have dug a few 20 m deep holes in other places, there is a good chance that we can dig a short tunnel at the 20 m level from the bottom of some other hole.
How did I survive that first job-gig teaching an API that I had myself never used before? Well, having studied functional programming in depth (using e g ML) had made me comfortable with the ideas of abstract datatypes. So the idea of an API was not unfamiliar. Having studied linguistics I was very familiar with formal grammars of languages so SQL syntax was not strange. Having studied compiler technology I could understand the semantics of SQL. Having studied algebra and set theory I could easily pick up how SELECT and JOIN worked.
It took me a few days to read the JDBC API and specification combined with some small hacks to validate that I had got it right. And after those few days I did not only knew about JDBC, I actually understood it well enough to be able to teach it in a reasonable way. Not being an expert, but reasonably competent.
Without the deep knowledge in some very obscure subjects (linguistics, set theory, compiler technology etc) I would have been utterly lost. No skill in "searching information on the web" would have helped me the least.
The more I learn, the more I realize how little I know. It creates contradictory feelings towards the field I love. To twist it even further the part I love the most is that you can never be fully learned and that there is never a ”right” answer.I understand the frustration. But I am not sure I would like to have a field where there was a right answer, a proven best practice - many in our field dream of such.
However, to me a large portion of the beauty of the field is that we are constantly pacing unchartered terrain. The challenge is to constantly search your tool-box for something that seems applicable, to adapt, to improvise, to search, to try, to fail, to back up, to learn, to grow, to try again, to discuss, to exchange ideas, to finally nail it.
This is nothing but my own personal experience, but if I should offer an advice to handle the world of information we have around us it would be the following:
Find things to learn that you find interesting and that challenge your intellect. Take the time, pain, and pleasure to learn a few of those things to depth. The deep thinking will etch your brain in ways that will help you enormously whenever you approach a new field. And enjoy the pleasure of deep understanding when it dawns on you.
PS Should you come across Sofie and Anton, take the time to have a discussion with them. And do not stop at a chat about everyday things - they have really interesting ideas to delve into.
I’ve been a huge fan of messaging systems and distributed application design through messages for a good number of years now. I’ve written several articles on this general area of development, and my MarionetteJS framework took a lot of influence from messaging based architectures. It’s been a part of how I think for a long time now. But until last year, I had never used RabbitMQ. What’s even worse is that until very recently (like, within the last 2 weeks), my use of RabbitMQ was mostly hopes and prayers, constantly wondering if my code was going to crash again.
But I’ve started to correct that mistake – the mistake of not properly learning RabbitMQ, and assuming that it worked in a manner similar to what I was used to. Turns out it doesn’t… big surprise… but it can be used in a manner that I’m more accustomed to, given the right libraries on top of it. So I wanted to offer a couple of quick lessons learned from my experience in trying to learn more about RabbitMQ and improve my use of it. I also have a few resources you may want to look at, and a recommendation for NodeJS libraries.Lesson #1: One Connection Per Client Process. Many Channels Per Connection
This lesson alone was my biggest break-through in understanding RabbitMQ – and it all stems from how RabbitMQ manages connections to the server vs how you actually interact with the server.
In RabbitMQ, you have a connection and a channel. A connection is what it sounds like – it’s the connection between a RabbitMQ client and a RabbitMQ server. This connection travels over the TCP/IP sockets or whatever wire protocol you’re using. The thing about connections that I didn’t understand, was that they are very expensive to create and destroy. A single RabbitMQ connection is a single TCP/IP connection. You want to avoid having too many of these open. In fact, I would go so far as to say you want to limit your RabbitMQ connections to one per client process. That is, if you have ApplicationA, a single RabbitMQ connection should be opened by and maintained by that application instance.
If Connections are TCP/IP (and they are, really), then Channels are the next protocol layer on top of Connections. Think of it like this… when you get on the internet, you have an open connection to some server somewhere. You can then choose to use HTTP, FTP, WebSockets, XMPP and other instant messaging protocols, and more. These protocols on top of TCP/IP are the communication channels that your applications use while connected to the internet. A channel in RabbitMQ is similar. It’s the thing that your application uses to communicate with the RabbitMQ server.
Here’s the best part about channels, though: you can (and should!) have a lot of open channels on top of a single connection. You can create and destroy channels very quickly, and very cheaply. They allow you to have a single connection to the RabbiMQ server, but have sandboxed communication for various parts of your application. Channels are how your application communicates with the RabbitMQ server.
So, keep one connection per client process (instance) and many channels within that process (instance).Lesson #2: Learn The Channel-Oriented Protocol / API Before Learning An Abstraction
One of the main reasons that I had a hard time learning RabbitMQ initially, and why my code was so terrible for so long, was my lack of understanding in how RabbitMQ actually works. When I started using it, I jumped right to a library that provided some abstractions on top of the channel-oriented nature of the protocol and I didn’t understand the abstractions. My lack of understanding the protocol itself was to blame. I couldn’t understand why the commands I was issuing were happening through the channel object all the time, instead of using Exchange and Queue objects like I expected.
It turns out the protocol itself is very channel-oriented. Understanding this opened my eyes as to why the library I was using was set up the way it is. I think there are possibilities for improving the API that we interact with, on top of the channel-oriented API set… and I’ve found a library that I’m using on top of it, that I like.
The point is, before you jump off the deep end and put yourself in a bad situation, like I did, take the time to learn the AMQP protocol (which is what RabbitMQ runs) and the RabbitMQ extensions to it. Having this foundational knowledge will make it easier for you to see which library you will want to use, and understand the options and API within that library. If you don’t learn the protocol, you’ll likely end up confused like I was.Some Resources For Learning RabbitMQ
I found it incredibly easy to get started with RabbitMQ, but had a little more difficulty getting anything more than a “hello world” message going. It wasn’t until I started reading additional resources, other than what is listed at the RabbitMQ homepage, that I really started seeing how to build things and why. Here are some of the resources that I’ve been using:
- The RabbitMQ Docs - the official docs. Be sure to check out the tutorials, as well
- RabbitMQ In Action – the best book that I’ve found on the subject, and the book the finally taught me what I was doing wrong with the API / protocol. I HIGHLY recommend picking up this before and reading the intro / first two chapters before you start coding
- Alex Robson’s Notes On RabbitMQ - I asked Alex a few questions a while back, and he posted this amazing gist of info. This is something I still go back to on a regular basis, to verify the direction that I’m heading against the things that Alex has said. It’s not something that can be consumed / understood in one sitting, by a n00b, though. Keep it around as reference material, like I do.
There are countless other tutorials and blog posts around, but not that much from which I’ve learned much. I find myself continuing to go back to these resources for the info I need.My Choice Of NodeJS Libraries
When I first started trying to really learn RabbitMQ (after having used it for a while), I found myself with a dilemma: which of the many NodeJS libraries do I go with? There are three major players at this point:
Node.AMQP might seem great off-hand, but from what I’ve read it is odd in that it hides exchanges or channels or something like that. I’ve only read enough about it to know that I don’t want to use it. I haven’t actually tried it, but I doubt that I will.
BRAMQP is a very low level API on top of RabbitMQ. It positions itself as letting you do ANYTHING with AMQP, because it’s a very low level driver like API. But the problem is that you have to do everything yourself. This is a great choice if you’re building a solid abstraction on top if a mountain of RabbitMQ knowledge and experience. I’m not there yet, so I’m not using this one yet.
That leaves AMQPLib (AKA “amqp.node”) – my current choice of NodeJS library / drivers. This is the channel-oriented API that I mentioned previously, and was confused about at first. Having learned through the API and the way RabbitMQ works, though, I find it fairly easy to understand and work with.
But I wasn’t super happy with using a somewhat low level API library in my code directly. I wanted to build domain specific objects for my application to use, and I wanted them to be based on the Enterprise Integration Patterns that I cut my teeth on, in the messaging world. So I started building my own wrappers to give me pub/sub, point-to-point and other semantics that I wanted. Well it wasn’t long until I realized that the author of AMQPLib had already solved most of this for me, with his Rabbit.JS library.
Rabbit.JS provides some of the core Enterprise Integration Patterns in a library on top of AMQPLib. If you’re coming from an EIP background when trying to learn RabbitMQ, I still suggest starting with the core and fundamentals of RabbitMQ. But once you get the basics down and you understand what an exchange is and how it can be used properly, then you should look at Rabbit.js. I’m finding it to be quite nice to work with and build my domain specific objects on top of.Other Resources?
I’m quickly growing fond of RabbitMQ and my choice of libraries for working with it in NodeJS. I’ve found some good resources, as I’ve noted above, but I’m sure there are other resources around, and other opinions and advice, too. I’d love to hear what resources you would suggest for someone learning RabbitMQ – especially on NodeJS, but any language would be good, really. Drop a note in the comments below, and let me know.
The book: The 5 Elements of Effective Thinking by Burger & Starbird.
In the audio format I found it hard to visualize the 5 elements, perhaps because of the analogy to the classic elements of earth, fire, air, and water. So before any confusion sets in, here are the author's 5 elements:
- Grounding Your Thinking; Understand Deeply [Earth]
- Igniting Insights through Mistakes; Fail to Succeed [Fire]
- Creating Questions out of Thin Air; Be your own Socrates [Air]
- Seeing the Flow of Ideas; Look Back, Look forward [Water]
- Engaging Change; Transform Yourself [the Quintessential element]
Each chapter is illustrated with wonderful stories. An example: JFK's 1961 speech to Congress in which he challenged the US: "I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to the Earth." The result of this challenge was not to start putting people in rockets and sending them to the Moon. It was much simpler steps that built upon previous learnings. Their example is the Ranger program, in which NASA tried 6 times to just hit the Moon, and failed before succeeding in the seventh attempt to crash Ranger 7 into the moon. Learning in each attempt, solving bigger more complex problems by iteration.
He has noticed that when projects scale-up, one of the first issues organizations must confront is how to manage a Product Backlog across multiple teams.
Some organizations work from one master backlog managed by a Chief Product Owner or a Product Owner Team. Multiple teams then pull stories from that backlog.
Other organizations have teams with individual product owners who create their own backlogs and release their own modules into a loosely coupled framework. Spotify has set up their entire organization to enable this. (They also carefully manage dependencies across teams.)
There is a whole spectrum of options between these two examples. The right answer for any company lies in their own context. If you're building something where all the modules are intimately integrated, a single, tightly managed, master backlog may work well. In a different environment, it might be faster for individual teams to continuously release improvements on their own module. There is coordination on the epic level, but Sprint-to-Sprint, their backlogs are independent from each other.
These models work for different Scrum implementations and we know there are even more ways of doing it. We would love to hear your story so we are extending an open invitation to the Agile community:
How do you manage your backlog across teams?
We want to learn how your context shapes your practice. Why do you do it that way? What kind of product are you building? How many teams do you have? And how is your method working for you?
Please post your answers in the comment section or on Jeff's Facebook page, or on Twitter if you are that concise (@jeffsutherland #ScalingScrum).
As the conversation winds down, we'll write a blog and compile the most interesting and effective techniques so we can learn from each other.
In the coming months, look forward to a Scrum Inc. online course in which Alex and Jeff present a framework for scaling Scrum. They will also share this framework at Agile 2014 in Orlando.
Wired magazine has a nice little summary of personal kanban. Check it out!Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
It has been a few weeks since my last post but the good news is I have been spending this time putting the finishing touches on a book. I plan on getting it off to the copyeditor by the end of the week and will let you know a release date shortly thereafter.
In the meantime, I wanted to share a simple and low effort coaching technique I have been experimenting with. It’s my favorite for now but I’m sure something new will replace it.
As an enterprise agility coach, we are often bouncing from team to team or from problem to problem. So much so that we may be missing opportunities to strengthen our impact and make deeper connections with the people we are coaching. I found myself in this place of months ago so I decided to try something simple.
Around lunchtime and as frequently as possible, I would plant myself at a table in the break room. I am currently working at an organization with small lunchrooms on every floor so I would find the closest one, sit down and just wait. I would catch up on emails or get a little work done but I make sure to not act overly busy or have a “don’t bother me” look.
Initially, when people from the teams I was working with walked in they would just say hello or we would share pleasantries. Before long, they would stop and chat a little more about “agile” things. And after a while longer they would start opening up about their experiences on the team and within the organization.
Over the past couple weeks I have noticed a few side effects to setting up informal “office hours” during the middle of the day:
A building of trust. Being in an informal setting seemed to lower defenses and there is an easier time to connect on a personal level. When this connection is developed, advocates emerge. These advocates help to remove resistance.
Hearing what people really think. Being in an informal setting seemed to allow people to open up a little more. They started getting more comfortable sharing the pain points they have been experiencing and were perhaps reticent to share in a group setting.
A chance to elaborate teachings. Many teams are learning how to be more agile on the fly (see the post “Working on a Beating Heart”). It may be tough to provide additional details on “the whys” while in working sessions. During some of these lunch breaks people would just ask questions and we would discuss how to make something work for them.
An opportunity to learn and improve. I started learning about ways to improve my coaching and how people were receiving my teaching style . I heard this before but I was recently reminded that I start talking faster when I get excited about something. I still need to work on this!
Something simple to try. I would also recommend this technique for any leaders out there. Please share your coaching tips and experiences in the comments below.
Since this interview was recorded, there has been an interesting debate of the Scaled Agile Framework (SAFe). In order to better understand the SAFe framework, well known and respect Scrum Trainer Ron Jeffries attended a SAFe training course. Ron Jeffries wrote about his experience in this blog post. Although Ron has his reservations with SAFe, his respect for Alan is quite clear:
His Agile values and approaches are quite good. That meant that his sections of the lectures, and his answers about what he’d do in real cases, shifted the balance from what I believe we’d have gotten from the other instructor alone.
Al responded with a well reasoned and thoughtful reply.
… I do not agree the best way to achieve scale is always by getting the teams working well. As with most things, an approach depends upon the situation you are in. If the types of projects you are working on don’t require teams of more than 30-50 folks, I’d probably take Ron’s approach, because SAFe is likely too big for them. But many projects are too big or complex to unwind. In this case, looking at the big picture and getting teams to deliver in 2-week cycles may be the right approach.
This is a short interview, because I goofed and stopped recording after about 30 minutes. Even though the recording ends abruptly, I thought the start of the interview very interesting and worth sharing. Here it is:Transcript [music]
Interviewer: Let me, very briefly give your background about what I was
trying to do. Maybe a couple of years ago, I felt like I was losing touch
with the people in the Scrum community. My wife and I, we moved out here to
Australia about four years ago. And Australia is a long way from anywhere.
And I felt like, I was starting to lose touch with people, and there were
new people coming into the community that have not met and were people that
I had not seen for a long time, such as yourself. And so, what I wanted to
do was, I wanted to find an excuse to reach out and talk to people.
Al: And that is cool.
Interviewer: Yeah, and I am of these people that needs an excuse to do
things. So the excuse that I created for myself was, that I would do
interviews and I would do interviews to ask people, about how they came
into the Scrum community. Just to chat about, where they came from.
Al: Okay, and in my case may be, how I got out of the Scrum community. I
guess am still in it, just not in the Scrum Alliance community.
Interviewer: Yeah if you are willing to talk about it. Personally, I
would be really interested to hear about that story. I do not know the full
details, I know some of it, but I would love to hear about the full
Al: I got in really early and if you are recording now that is fine, I am
cool if you are.
Interviewer: Yup, yup.
Al: That is fine, yeah. So I got in really early, I do not remember
exactly when. But I was doing Agile, well I knew that is what I was doing
because I think I was doing it beforehand, and did not even know that is
what it was called. But as early as 99, when I heard Martin Fowler talk
about extreme programming. I thought “Wow, this is cool stuff.” And by 2000-
2001, we were doing Scrum. I do not know when Ken’s book came out, but
whatever year it came out, I read it. I was at all the early Scrum
gatherings. Actually, we sponsored one of the early ones when. Like I
remember one of the gatherings we went to, there were like 50 people, that
might have been the first one. And the first two or three or four years, I
was really avid about Scrum because at that time, there was no good way to
explain, why doing things in this steps make any sense. I mean intuitively,
I had been doing it for a while. But from a business point of view, it was
difficult to explain. And Ken was really good at explaining.. And I thought
wow, this is really cool. This adjusting and responding and building small
pieces, and this discipline. Agile and Scrum were at that point, not quite
synonymous, but iterations.
I remember, I would describe Agile as iterative, incremental and
integrated. That if you are doing those three things, that was the essence
of it. And Agile and iterations, these were sprints, to use the Scrum
terms, they were connected. The thought of what Kanban and flow is now,
that just never occurred to me or anybody else I think. So I was actually
really into the Scrum community. We had a lot of CST’s, like other people
did. I never became a CST because basically, I was doing other things, and
I was the CEO of Net objectives, still am. And being a CST seemed to be,
not where I should be focusing because then, there was a very limited
number of CST’s in those days, it was very difficult to become a CST in
And basically, but I had a couple. We did a lot of Scrum training. I
did other kinds of Agile training. And this went on for about three or four
years until 2004-2005, when two things started bothering me. One was, we
kept running into organizations where Scrum would not work, and it would
not work for any number of reasons. And one of the reasons was, if it was
big, there was no way to create a common vision to get people to work
together. And as Scrum as Scrum, we never could figure out how to get that
to work. In fact, we never did, we did other things right from the very
beginning. I go back to my early writings, and we talked about, I cannot
remember what we called it, but it was some group, that now is actually
kind of, you could think of it as a separate group of product owners,
talking to each other. But I forget what we called it back then. But it was
the early stages of some, high-level contextual view of, how to manage
multiple teams of multiple projects, working together.
So one thing was, this lack of vision, to create, for people to come
together. And the other problem was, there were times when Scrum as a team
method framework, would not work. Iterations were just not the right
approach. Having cross functional teams, were not the right approach. And
all I would ever hear was, “No Scrum will always work, you just have to
follow it.” And I am like, “Well, that does not make any sense. There are
times you do not want to follow it. There are times when you have key
people and you cannot get somebody with the experience you need, on every
team. Then what you do?” And nobody was listening to me. It was very
frustrating. And what started happening is, I started bringing the notion
of Lean in because I started seeing that Lean could create the bigger
vision. I did not know how to solve this problem with key men or key women
or whatever. But there were some things about Lean that seemed very
appealing. And I started talking about it in the community, and it was
really bizarre because, when I was talking about it in the community, I
would get a positive response. But I would be with Scrum folks, but if I
were talking about it openly, I was slapped on the wrist all the time. And
eventually that led to me being thrown off the Scrum development group
because it could not slow me down because Ken did not like me talking about
So that was a piece of it. The other piece of it is, I really still
do not like the way the SCRUM certifies trainers, because what happens is,
companies make investments, get a CST and then the CST leaves. I thought,
that was a bad business model. I told Ken, that was a bad business model.
The moment he came up with a CST program I said, “This is not a good model
because, it serves the individual, it does not serve the organization.” And
then every year you would see people getting CST and then leaving the
company, setting up their own shingle. And I just personally did not like
it, even though everybody was making a lot of money out of it, it did not
seem right. So those two factors really had me decide, “Well, I got my
hands tied when I am in this community, so I am going to go elsewhere.” It
did not change my opinion to Scrum. I think Scrum is a really good
framework, for teams to work in. We do a lot of Scrum. We teach Scrum all
the time. We do safe silver partners, and it’s based on Scrum. But I do not
like the way it was being organized to expand, and that is basically why I
Now I admittedly, I might have left in a calmer way or, might not
have did something, I am maturing. But that was my main thing you know, it
was not Scrum itself. So, I also got to say, I really like what Ken did
was, Scrum.org. We had been talking for years, that you needed to do team
training and not certified Scrum Master training and when he started doing
that I said, “Good for you, that is what you should have been doing for
years.” I had been talking about that as well to no avail. So I think there
were certain resurgence of technical practices into Scrum and it is a team
training now, instead of a Scrum Master training, is really important.
Because if you think about it, if you have only got two days to do
training, if you spend any time on how does a Scrum Master be, that is time
less, for, how does the team be. So, if you want to be, if you want to do a
three-day training, that explains all the Scrum Master role and all the
team role, that is cool. But most people do not have that kind of money or
time. So I think, Scrum.org actually is moving in the right direction, with
how they are going. They are also going through the rep approach, where you
have materials and people get sort of being able to do that. So, I guess
Ken’s learned some of his lessons, because I am not interested in working
with Scrum.org, but I have got to say, but I like the model. It is a whole
lot better, than what I saw, when I was with the Scrum Alliance, and then
Now the other thing we have done and it is funny because I have been
accused of liking one thing or promoting one thing. And what is ridiculous
about that, is I am the only guy who does everything. I mean think about
it. I do Scrum, I do Kanban, I do XP. I used to be an accredited LKU
instructor with the Kanban method. I still do the Kanban method. It is just
one tool I have in my toolbox. I’m the only guy carrying around six tools,
when everybody else’s got two or three. And they think they have a variety.
So my thinking actually, the big umbrella for me is Lean. Lean is kind of
mindset and a framework. And it is based on just a few key principles that,
I guess the essence of Lean for me goes back or the foundation, not the
essence. There is a difference, on what it is built on, goes back to
something that I have been doing for, 30 years and that is Deming [sp].
Look to systems, trust that people are basically good, and if you put
them in a good environment, they will do good work. If you put them in a
bad environment, you will suppress them and they will not get good work
done. And that, you do not need to, try to cajole [sp] them to do good
because they naturally want to do good. But you have got to remove what is
in their way. And that takes improving the system, but it also takes good
management. It is not something that people by themselves can do because in
a big organization, there are lot of impediments that the individuals
cannot do. But create the right environment, then let them do well, self
organize within that environment. And then Lean, builds on that foundation,
by adding the notion of, do not stop the workflow. When you start work,
keep it going until it is delivered. Well the only way you can do that is,
if you have got small batches. So, Lean talks about just in times, small
batches. It actually talks a lot about testing, which most people I do not
think, realize. Because most of the books that I read about Lean, do not
talk about testing.
But if you go back to [inaudible 00:10:51] book, the production
system, he talks about this thing called autonomation. And he means
automation with a human touch. And of course, manufacturing is a lot
different from software, so do not try to do this in software, what they do
in manufacturing. But take the essence of it. The essence of it is, things
should run well, and when they do not, then you stop and figure out what it
is, get it to run well again and then you continue to skim through the
system, once something goes wrong. But you should not be testing things in,
and you should not be having to manage the process, it should flow
smoothly, as you do things. Excuse me, just allergies.
Interviewer: It is all good.
Al: So, the more I study Lean and the more I talk to different people,
outside of the core Lean community, a lot of things fit into it. Like Bob
Charette actually, I did not know this, but he actually was the one who
coined the term Lean software development. He wrote a paper, I think it was
in the 90′s.
Interviewer: Oh, really?
Al: Yeah, Mary and Tom did not coin the term, even though they are the
ones who get all the credit for it. Charette wrote, and I do not remember
what year it was, it could have been, as early as 89, but it was definitely
no later than ’99. I think it was a late 80′s. He wrote an article called
Lean software development, and I did not know who Bob was, until about five
years ago, at the first Lean Kanban conference. He was there, not was the
second one, it was the whatever was after Miami. It was that one and he was
there. And he told me this, and I was talking to him. He is a risk viewer,
this guy is just amazingly smart. Probably, the number one risk guy in the
country or the world. And he was telling me about this. And he tied that
notion together. And if you start studying, if you start taking the
principles, the foundation I should say, these principles from Lean and
Deming and apply them to software, then the practice will show up
differently. But basically, the ideas work on a small value pieces, as you
can, and make sense from a deployment point of view. And do not work on too
many things, so you have to stop work.
I love David Anderson’s phrase, “Stop starting and start finishing.”
I actually came up with myself just the other day. It just hit me,
finishing, it is “Stop stopping.” Do you know what I mean? You are working
and then like, you stop. And you stop because you need somebody else or
just because you do not know something or you stop because the bug happens
and the testers are not there or whatever it is. You have a stoppage in the
workflow and that is bad. So it is like, stop stopping, how do you set it
up so you do not have to stop, so you do not have to keep stopping. And
these mantras really guide you, no matter where you are. Then Scrum, if you
view it as part of the Lean world, becomes a lot better because you can see
how to extend it. And I am happy to say that the Scrum community is finally
acknowledging it’s a manifestation of Lean. I have to admit, I still get a
little irritated, I get less and less as time goes on because I am maturing
a little bit. But I get a little less irritated every year that, back six
years ago, when I was saying this, I was told, “No it is not. No, it has
nothing to do with Lean and all that.” But it is at least good now that it
is being said that it is Lean. It is a partial implementation of Lean
thinking and it is quite good. And when you actually acknowledge that and
see that, then when it does not quite work, you can use Lean thinking to
get you to the next level. That is why, I am not trying to say Scrum is a
part of Lean or kind of Lean, so you will do Lean. I think, that is how you
can enhance Scrum. In fact, I am doing a webinar in about four weeks, on
enhancing Scrum with Lean. Because then when you get stuck, you can say,
“Why do I have iterations?” And there are a variety of objectives, there
are reasons you have iterations.
When I am having trouble doing this one, maybe instead of just not
doing it, instead of don’t do Scrum but, I am going to look at, what is the
intention and how can I use Lean to get a better intention. There are two
kinds of Scrum buts in a sense. One is, “Well, we are doing some Scrum, but
it is too hard to do it this way, so we are going to, we are not doing
that.” And that is an accommodation, and that is virtually never good. Or
it could be well. “We are doing Scrum, but we cannot have fully cross
functional teams because one guy is needed for three teams.” So what we
have done is we have setup a Kanban work for this person, so we can be
sure, he crosses the three teams. So you know, that is good Scrum work
because you are getting the intention of it. So, that is kind of my
approach, is I am always trying to figure out what works, and then pull
from, whatever mindset there is. But if you just pulled from the mindset in
principles, it gets too theoretical. I mean, I am good with that, but most
tell me what to do. I need to know what to do.
Interviewer: Something practical, something.
Al: So then, yeah exactly. So that you want to, “Well, here you use this
part of Scrum or you use that part of Kanban”, but it is really, you are
just solving the problem-based on the laws of nature, of software
development, as a phenomena. Anyway, that is kind of what I do.
Interviewer: So you mentioned briefly through that, you mentioned
talking about using Scrum within Lean or I cannot remember the exact words.
Al: Yeah, within the context of Lean.
Interviewer: Within the context of Lean, yeah.
Al: So think about this. So one of the biggest problems people have with
scaling Scrum, is the inside the team, it works well. But across teams, it
has difficulties. So how do you solve that problem? Well, Scrum of Scrums
has been attempted.
Interviewer: Not terribly successful in my experience.
Al: Yeah, I have a standing request for anybody in the community to give
me one success of Scrum of Scrum working. And so far, I have got none.
Nobody has come to me. So it is like, just stop talking about it please
because if it does work, tell me and if it does not work, let’s stop
talking about it. But the reason it does not work, is inter-team dynamics
are quite different than intra-team dynamics, when it comes to decision
making. See, Scrum of Scrum works really well, when it comes to
communication. That is fine because then, you are just letting people know
and it is not a bad method. So, how would you coordinate teams? Well, does
not mean you do not do Scrum? Does it mean you have to do command and
control and a high big view, and the answer is no, of course not. You have
to use Lean at the high-level, to manage workflow. So you say, “What is the
biggest, what is the business increment we’re trying to deliver?” Think of
it from a corporate point of view, deliver value quickly. Now, how do I get
my teams to deliver value quickly? Well, maybe if I need to break the work
up, I need to break it up into way that teams can work together, so they
are working on the same things at the same time. Because if their working
on unrelated things, like in the first sprint, and then they work on
unrelated things in the second sprint, you cannot integrate, you cannot
test, if you have got it working.
These are all the dependent things, “First we are going to do that,
then we are going to do the next sprint, that are related to each other.”
Then you are shortening the time, you are cutting out the delay between
building something and then, validating it. So if you say, you want me to
use Lean to make sure that my workflow is quick. I get something started
and done, started and done, then I can now do Scrum within that context,
that is what I mean by doing it within the context of lean. I also mean,
recognize that the reason Scrum works in my opinion, is not so much that
you have self organizing cross functional teams, but by having cross
functional teams. You basically cut out a lot of the amount of work in
process you have, and a lot of delays you have, inherently. Well if you
recognize that, then when you have a backlog for the Sprint, what you will
want to do is, even if you are not managing work in process, you will still
say, “I want to have as few stories open as possible” because it is Lean
concept. Then I will do things just in time, instead of all at once. So I
am doing Scrum, but I am doing it within these kind of rules and things
like that. That actually helps a lot.
There was one thing that crossed my mind, I was talking to you, just
to kind of float it through, but it was just as good a concept. To explain
this about Scrum within Lean, but I guess hopefully it will come back. That
happens to me, at times. If I said everything that was on my mind, you
would have about three conversations going on at once. Sometimes something
goes through there, and I can’t say it, I cannot remember what I said.
Interviewer: Happens to all of us.
Al: Yeah, well you see the other thing about this is then, if you think
about it, if you do Scrum or if you do Kanban, you can mix those two
together, as long as they are within the bigger picture of concept, context
that you are working on. So that is what is really good. So in a lot of
ways, the intention becomes, does not matter if you call it Scrum or
whether you call and Lean or whether you call it Kanban, the real question
is, why are you doing it. And the labeling is, just so you can talk about
it like a process pattern. So to me, Scrum is a process pattern. Kanban is
a process pattern, Kanban method is a process pattern and XP is a process
pattern. But that assumes, you are coming from the perspective that in
fact, there are laws of nature, of software development out there. Not
everybody agrees with this by the way. This is where Ken and I would
disagree, if we ever talked about it. We have never had that option. There
are many in the Scrum community, that do not believe, you can talk about
workflows and value streams, without causing a lot of problems. I
personally think you can, because I have seen it, I have done it, it helps.
But there are a lot of people that think you become mechanistic if you do
that. And it is possible, to become mechanistic.
I think Kanban method can become mechanistic. I have written about it
in a blog I call framework myopia, where, if you focus on one thing, then
you tend to ignore other things.
Interviewer: That is right, yeah.
Al: And our whole physiology, I usually do not try to study psychology.
Actually I study psychology and physiology a lot because, just as a hobby.
I think it is really fascinating stuff. I got a background in psychology, I
have always been interested in psychology but. It is interesting, if you
study it, you will notice, the body, the brain, our whole physiology, our
whole cognition, is geared around focusing on one thing. We are designed as
beings, to focus on one thing. And we have some sensors that give us
peripheral vision and things like that, but in fact when you notice, if we
are in a fight or flight response, things just gel down to what we are
afraid of, we give our full attention to that. So the danger in software
development in my mind, is when you start focusing on one thing. And you do
not notice the other things. You just do not even see them. It is not like
to see them and discount them, they would never show up in your cognition,
in your consciousness. And that is what I meant by myopia. Because myopic
people, they see something, but it is very limited and they cannot see
around it. And we are kind of becoming that way.
So, that is my latest rant, is I’m trying to get people. How do you
see what you need, and then how do you learn how to see what you need next?
And this is something that neither Scrum nor the Kanban method talk about.
Scrum just as we’ll start removing impediments, but they do not tell you
how or what. Kanban method says, work in process and you will figure it
out. Okay great, but why should I? Because you are smart and we respect
people. And I am saying, well if you respect me, you would not make me
reinvent the wheel. See that is another difference in attitude. I respect
people, I do not want them to waste their time figuring out what other
people have figured out. To me, that is wasting their time. So there are
differences and those differences are actually, it is not the difference in
Scrum or Kanban or Lean. It is the difference in those mindsets, how do you
help people, how do you learn, how many things do you focus on? Are there
rules to software? What are those rules? Those are the differences.
Interviewer: And so you mentioned, just briefly about rules of
software. That software has natural rules. Could you expand on that a
little bit? Because that is kind of interesting.
Al: Yeah, there are not a lot of them, but there are a few that are
reaching. So one is, if you start work and then stop it, and then you pick
it up later, that will cause more work to be done. And people call this
task switching, and it is not. You test switch every morning, you go from
seeping to waking. So if I work on something Monday, and then I put it
aside and I pick it up on Tuesday, task wise. If I stop working on
something Monday, and I pick up something else on Tuesday, I task switch.
If I work on one thing a day, that is minimal task switching. But if I work
on project a on Mondays, and then I work on project B on Tuesday and then
project C on Wednesday and I come back to A on Thursday, I will not be as
efficient, as if I work on A Monday and Tuesday and Wednesday, until I
finish it. It has to do with short-term versus long-term memory. And it
creates additional work for two reasons.
One is, I do not remember where I was, but what is worse, someone
else might have been in my code or somebody else might have changed the
requirement and I cannot get the response I want, fast. So that is a rule
of software, that if you delay the work flow, where it is not in your
advantage to do so. I mean sometimes, “Oh my brain is fried, I have got to
set this down.” Okay, and that is good. But I am talking about
interruption, talking about, I am working on something, I stopped, I go do
something else, I am not coming back to it, that will cost me time. If
requirements age, if I get some requirements today, three months from now,
they are not as good. That is not your opinion, that is not my opinion,
that is just the way it is, those are the things I am talking about. If I
work on really, really big things, in parallel with each other, it will not
work as well as, if I get something done and finish it.
The Agile community and the Agile manifesto refers to some of these
things. But it does not make it clear and explicit enough. For the example,
finished code is a better measure than have I got some artifact in front of
me. Yeah, it is not my opinion it is not your opinion, it is just the way
it is. That is what I mean when I say, it is not our opinion about it. We
have nothing to say about it. You can like or dislike gravity, but it is
still gravity. How you talk about it, might make you more effective in
dealing with gravity. But whatever phenomenon is out there, it will pull on
your, regardless of what your opinion about it is. So there are things like
that in software, that a lot of people are actually denying. They are
saying, “Well it is complex.” And I am not using complex in the Cynefin
model or even, they are not exactly consistent. Cynefin or [inaudible
00:26:01] talks about it being, “You cannot get cause and effect.” And the
answer is, it is actually not what it means. It is not what complexity
means. There are patterns to complex things, and you can get some cause and
effect, you just do not get exact predictability. I can guarantee you, if I
go into a movie theater and scream fire or scream bomb, or shoot a couple
of shots in the air, I am pretty sure, they are going to leave, and
screaming and yelling is going to happen to.
What exits they go to, I cannot predict that. But there are certain
patterns of behavior, you can definitely predict. So, even complex systems,
there are rules. The cause and effect may not be totally clear, but that
does not mean there is nothing. It just means we do not necessarily
understand it, but we can sometimes see big pictures of things. So this is
an area, that people have pretty much ignored, not everybody. Don
[inaudible 00:26:56] book, I have not read it. Principles of lean product
development flow, this is like a bible of software engineering. It is just
an amazing tone, definitely read it. It is Don [inaudible 00:27:08],
principles of. It is [00:27:11] book. I thing it is, principles of Lean
Interviewer: I will look it up, I will look it up on Amazon post it to
Al: Yeah, it is not an easy read, I will warn you. Principles of product
development flow, second generation Lean product development. But it is
brilliant, it is a brilliant book. Lots of equations, lots of graphs and
stuff. But it is not hard to read, I think is very clear, but you have to
read it carefully.
Interviewer: You have got to give it your full attention?
Al: Yeah, it is not something you. You have got to give it your full
attention. But if you give it your full attention, then you will understand
it. It is very well written. Whereas I have read some books like, the Gang
of four book, when I first read that, I was like, I was giving it my full
attention and I was hitting a brick wall. But six months later, I got this
insight, that broke that the whole thing open for me. But I read that for
months saying, “I know that there is some good stuff in here because I can
smell it, but I do not see it yet.” That was an interesting, that was a
design patterns book. That was a book that was really up to, has
brilliance. Then when you break the code, it becomes, “Oh my goodness, this
is such an amazing book.” But it was very difficult to get to that point.
Interviewer: So just taking a quick step back, just to trace through
your path, through Scrum and through Lean as well. You mentioned right at
the very start, you were introduced to extreme programming by Martin
Fowler, and then you moved into the Scrum community. At what point were you
thinking heavily on Lean? Because I seem to remember that we chatted at
Amazon on, in 2008 and you were already starting to think quite heavily in
the Lean fashion.
Al: It was about 2004-2005, that I started getting into Lean in a big
Interviewer: So that was quite early on actually?
Al: Oh yeah, yeah. Because the basics of Lean, I had in 83. I used to
study Deming, back in 84. It was actually 84. So when Mary, I met Mary
before the book came out. She was also in the Scrum community and we
chatted a lot, back then. So I made the connection with her back in 2002-
2003, heavy in 2004. And so Lean made immediate sense to me. It was like,
“Wow, this just explains a whole bunch of stuff.” And I could never get Ken
interested in going down that path. And every time I would talk to him, he
would say he was interested, and then when it actually came time to action,
it was always well, “No, I am doing my thing.” We never could agree. And
then, for a year or two, I was like, “Man, I really hope the Scrum
community will absorb Lean and move in this direction.” But since nobody
was interested, then after a couple of years I started thinking, “Well I am
going to talk about this. I am talking about it inside the community and
nobody else is doing anything about it.” So apparently, it was okay to talk
about it inside the community. But once I started talking about it outside
the community, people did not appreciate that. Because they could not
control it, I guess.
So when we started in 2008, I had already been doing Lean for a few
years. My problem and it was right about that time that it started shifting
for me. My problem was, I just had Lean as a theoretical framework, that I
could sometimes intuit solutions out of. And I did, there were some things
that we did, that were really cool, really remarkable. And when I look back
on it, I recognize, I was managing flow well, and a variety of things like
that. But it was not until I started doing Kanban, which was right around
2008, that I started having a set of practices, that would implement these
principles. Then I understood the principles, but I did not understand, how
you would actually manifest it. On hindsight it is like, wow, I do not
quite see how I missed it, but I did. So I have David to thank for that
because he made it really clear. Actually, he did not invent Kanban, but he
was the one who promoted it. There were a couple of hundred people like
Orbis and Microsoft, who invented it. But you know, the same way that Ken
did not invent Scrum, Jeff did. Ken formalized it and so, around 2008-2009,
all of a sudden I had a way to make Lean work, from a practical point of
And at that point though, I did not truly appreciate the importance
of teams. So I kind of went from heavy Scrum to heavy Lean. And then I do
not know, couple of years ago, I went back to, more mid-range. Believing,
teams are great, always try to get to them if you can. And jump as far as
you can, but you do not over jump. So, the Kanban method rather, of always
doing incremental improvement makes sense, if that is all you can do. But
it does not make sense if you can actually rearrange workflow, use minimum
business increments or whatever. And this is where David and I started
splitting up to some level, as I started talking about. “Well the Lean
method is great, but it is just one of many things.” And he did not want to
hear that. So, basically what happened to me… [voice stops abruptly]
In any Enterprise-scale Agile transformation, having the right structure and governance to support how work flows through the organization is crucial to having a successful transformation (see “How to Structure Your Agile Enterprise“). Business Capability Modeling is a method LeadingAgile uses to inform and customize our recommendations around this structure and governance. We work closely with our clients to develop their unique business capability model. We then heat map the capabilities in terms of business value, performance, and risk, based on interviews with key stakeholders. The resulting heat-mapped capability model promotes a shared understanding and can be used as a basis for how to structure teams (what to form the teams around) and for prioritizing and scoping work.
The Capability Model is a modular description of a business in terms of desired business outcomes. Desired business outcomes are identified and defined at each level of detail in a hierarchical fashion. So for example at the highest / top level of the hierarchy we would have for a typical business capabilities like “Develop and Manage Products and Services”, “Market and Sell Products and Services”, “Deliver Products and Services” and “Manage Customer Service”. Complementing these operational capability areas are supporting capability areas like “Develop and Manage Employees”, “Manage Information Technology”, and “Manage Financial Resources”. The American Productivity and Quality Center (APQC) is a member-based, non-profit that provides a “Process Classification Framework” (PCF) from which these examples are taken. LeadingAgile works with the client in a process of discovery to identify the client-specific capabilities, using the APQC PCF as a reference model.
The capability names are chosen to be action oriented, written in a verb-noun format, like “Acquire Inventory” or, “Authorize Customer”. The descriptions are written to define the desired business outcome, like “Maintain enough inventory to support demand”, or “Enable registered customers to use the system”. There are likely one-hundred or more capabilities across 5-10 or more major areas such as those listed above. This gives us a very useful model since it describes the business in terms of its “Whats” and not “Hows”. We need to avoid the “How Trap” when discovering and defining the capabilities. It’s so easy to go down a rat hole of discussion around how a business outcome is achieved. We want to stay focused on what needs to be achieved. This gives us an objective model of the business upon which we can have objective conversations. Meaning, without getting into how capabilities are achieved since that ties us to the current implementation.
As mentioned, the Capability Model provides a modular, outcomes-based description of the business. As such, this is naturally a Service Oriented model or view of the business. So, the business processes made up of the capabilities could be implemented in software with a Service Oriented Architecture. Thus, for greenfield development, the Capability Model could be used to help drive a Service Oriented Architecture (SOA)/ design and implementation. For legacy systems, it can be used to refactor the legacy architecture to be more Service Oriented, in addition to the other uses listed above. To learn more about Capability Modeling and SOA, see the Harvard Business Review paper “The Next Revolution in Productivity” by LeadingAgile’s Dennis Stevens, et al.
Also check out a recent post where Mike addressed the question “Is Your Business Model is a Good Fit for Agile“
yourkit is my favourite JVM profiling tool and whilst it’s really easy to profile a local JVM process, sometimes I need to profile a process on a remote machine.
In that case we need to first have the remote JVM started up with a yourkit agent parameter passed as one of the args to the Java program.
Since I’m mostly working with Neo4j this means we need to add the following to conf/neo4j-wrapper.conf:
If we run lsof with the Neo4j process ID we’ll see that there’s now a socket listening on port 8888:
java 4388 markhneedham 20u IPv6 0x901df453b4e9a125 0t0 TCP *:8888 (LISTEN) ...
We can connect to that via the ‘Monitor Remote Applications’ section of yourkit:
In this case I’m demonstrating how to connect to it on my laptop and am using localhost but usually we’d specify the remote machine’s host name instead.
We also need to ensure that port 8888 is open on any firewalls we have in front of the machine.
The file we refer to in the ‘agentpath’ flag is a bit different depending on the operating system we’re using. All the details are on the yourkit website.