Looking for a fantastic explanation about Scrum and Agile, but don’t want to wade through a bunch of whitepapers, convoluted diagrams and confusing explanations with words you’ve never used before?
Well, look no further! Here, you’ll find the answers to questions like, “what is Agile project management?” And, you’ll learn how you can implement Scrum to help your team.1. VDD stands for Value Driven Development
Do you know what the business expects from your current development? Do you have any idea about the most important features for the success of your project? You need a vision that describes who needs the product, why they need it and expected benefits. This vision is shared by stakeholders and the Scrum team.
Throughout the project, functionalities at the top of the product backlog are the ones with the highest business value. They are refined and discussed with the team.Every day, Scrum teams ask themselves: “Is this project going in the right direction or do we need to adapt?” 2. No more tunnel vision thanks to short iterations
Do you really believe a client is always able to express exactly what they need at the beginning of a project? Maybe the solution they are thinking about in order to solve their problem is far from ideal. But how can you help them discover what they really need before the project is finished and its too late? Agility introduces the idea of iterative development, and Scrum is implementing it with the concept of short iterations of time (2 to 4 weeks) called a sprint.Agile and Scrum embrace failure as an opportunity to learn.
At the end of each sprint, the team presents the client with what has been done. This means showing real working software, not just some slides or talking about a concept. Practitioners of Scrum believe it is the best way to share a common understanding to get the valuable feedback that is needed.
Every day, Scrum teams ask themselves: “Is this project going in the right direction or do we need to adapt?”3. Command and control no more: empower the people!
Scrum will make you reconsider the role of management. In fact, a manager will turn into a servant leader!
A manager’s job is to make sure that the people within the team possess the skills required to complete the project, as well as a good work environment. Then they need to step back and trust that their team is doing their best to reach their objectives and continuously improve.
But, managers in a Scrum world cannot disappear completely. They still need to help remove the obstacles the entire team might face, in order to progress.4. Dedicated and cross-functional team
Are you always involved with the same kind of technical tasks? (For example, only front-end development, only back-end development, only database, etc.) What about working on multiple projects at the same time? Do you sometimes lose focus and have to switch context in order to integrate your work with people who are working in other teams?
In a Scrum team, there is no more of that! No more multi-project and horizontal development: the team is collocated and dedicated to a single product backlog. Developers are full stack developers, who own a feature in a sprint from top to bottom, developing it as a vertical slice.
A good Scrum team is built for the long run; the product backlog may change after a project is finished, but the team will stay stable and move on to the next project.5. A sustainable pace. No overtime!
Is your team often putting in overtime? And if yes, why? Well, the answer is probably because there are fixed deadlines that need to be met! But is this really a proper way to work? (Hint: it isn’t.) Scrum follows the Agile Manifesto principle about sustainable pace: Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely. The idea behind this principle is not that Agile people are lazy. The point is to provide visibility in the mid- to long-term.
The only solution is to maintain a sustainable pace through time. If people put in overtime to meet a deadline in one sprint, then they should be able to compensate in the next.6. Introspection: The art of getting better
Agile and Scrum embrace failure as an opportunity to learn. Whether you fail because of something technical or because of a problem in your process, there is nothing wrong with that.
The real problem is when you fail, time and again, without searching for “why,” and without taking actions to prevent it.
Scrum has a dedicated ceremony to discover what went wrong during an iteration and to look for potential improvements: the retrospective. The Scrum Master is responsible for creating a welcoming, blameless environment where team members can exchange opinions. This meeting is crucial for the team and requires the most groundwork from the Scrum Master.
The Scrum Master should bring two things to a retrospective: a plan and a toolbox. Depending on what the team expresses during this meeting, the Scrum Master might have to adapt his/her plan.
As a beginner, you will often follow the 5-step retrospective from Esther Derby, picking innovative activities found online. Don’t worry, though, with time and experience you will create your own activities, and you’ll do what is right for your team.7. Communication
Speak a common language for transparency’s sake, and put the focus on face-to-face communication for efficient exchanges.
A ubiquitous language about the business and the process must be shared by the Scrum team and the stakeholders in order to better understand all the visual tools and the sprint outcome.
Promote enriched and clear conversations about quality expectations. This way specifications, designs, and architecture are able to emerge easily from the Scrum team.8. Say goodbye to over-engineering: YAGNI!
“Why are there so many questions to create a new user?! I just want to sign up!” It’s a legitimate question when the form in front of you contains too many fields.
This is where YAGNI comes in, which stands for “You Ain’t Gonna Need It”. Combine the VDD and short iterations to develop the minimal version of your features with a pragmatic code design.
Product Owners: challenge your business!
Developers: challenge your product owner!
You can then use feedback from your users to efficiently build features that fulfill your needs.9. Scrum is about people
“Individuals and interactions over processes and tools.”
This quote is actually the first statement and first value of the Manifesto for Agile Software Development. If anything, Scrum is about people and the way they work together. It focuses on the team members and their interactions, both within the team and within the rest of the organization.
Scrum also favors experimentation and knowledge sharing. Don’t hesitate to share your successes and your failures. And remember that you are not alone. There are a lot of Agile and Scrum communities with experienced practitioners who are ready to help.10. Scrum is based on the Agile values
We just mentioned above, the first value of the Agile Manifesto, but there are three more. Scrum reinforces these values.1. Working software over comprehensive documentation
In the Sprint review meeting, the team shows the concrete result of their work to the stakeholders by giving a demo of the working software. This is aligned with the second value. The product produced at the end of the iteration should always be potentially shippable, which means it could go into production.2. Customer collaboration over contract negotiation
In a Scrum team, developers are encouraged to speak face-to-face with stakeholders and users. They collaborate with them on a daily basis. The product owner is particularly involved in this collaboration and paves the way for the team to better understand what the users need.3. Responding to change over following a plan
Scrum embraces uncertainty and treats it as an opportunity. Planning short iterations allows the team to refocus its work on a regular basis. Your business just changed because a new competitor entered the market? Well, ok, no problem; a Scrum team can adapt quickly.
This piece is brought to you by Agile Partner, a Luxembourg-based IT service provider that strongly believes in the Agile methodology and provides software development and training.
On November 10th, Targetprocess Product Specialists Natalie Yadrentseva & Kate Makarevich will be holding a free webinar on how to implement SAFe with Targetprocess. You can reserve your spot for this webinar here.
SAFe has emerged as one of the most popular methods for scaling Agile. Its carefully designed framework has helped hundreds of companies to bring flexibility and speed to their entire organization. Getting started with the SAFe can seem like a discouragingly difficult task, but we will demonstrate how Targetprocess can backup your implementation of the framework.
Our upcoming webinar will showcase how to implement SAFe with Targetprocess and address some of the most commonly asked questions about the framework. Let’s take a look at the planned agenda:Introduction
We'll kickoff the webinar by discussing the value of SAFe: why it works, who can benefit from it, and where it came from. We’ll also go over SAFe’s data structure: the different levels, processes, events, and roles in SAFe, with a focus on how they can be replicated in Targetprocess.
This brief introduction will be a good refresher for those who are rusty with the framework or new to Targetprocess. It should only take about 10 minutes to cover everything.SAFe in Targetprocess
First, you'll see and understand how Targetprocess supports SAFe, both with and without the Value Streams level. We’ll define what strategy is (as it relates to SAFe) and then show how to communicate strategy arcs using Targetprocess.
Next, we’ll go over the views used for PI planning and team planning. You’ll learn how teams can synchronize with the help of a Program Board. We’ll also demonstrate how to visualize dependencies and relations between work items in Targetprocess.
At the end of the webinar, we will answer any questions you may have had over the course of the session. There’s no time constraints for the Q&A, so feel free to come prepared with as many questions as you like. By the end of the webinar, you’ll be able to go back to your teams with a solid grasp on how to scale Agile with SAFe in Targetprocess.
Again, the webinar is scheduled for November 10th, so feel free to leave us a comment if you have any requests for items you’d like to see covered. Have a great day!
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
There is a natural tension between the predictability an organization needs in order to plan and budget and the adaptability it also needs to accommodate for change and the unknowns. At the outset of a new project, especially if it is using new technologies, there can be an order of magnitude difference between how long we think it will take and what it really ends up taking. This is frustrating and even infuriating for anyone in charge of a budget.
We all do our best to estimate and plan and to nail down as many unknowns as possible. Traditionally, we have used requirements documents, GANTT charts and rigorous sequential processes to iron out the natural fluidity of a project. Change and the unknowns are treated like an enemy and whatever change we cannot control, we oversee with rigorous Change Control Processes and a steadfast commitment to as much of our original plan as we can salvage.
Intentionally or not, our traditional practices are designed to drive change and fluidity out. That may be because we inherited our project management metaphor from construction projects. For decades, we have shaped our software delivery practices as if we were building
a skyscraper and no-one could enter the construction site until after the whole thing was built and we had completed the ribbon cutting ceremony.
Software…and knowledge projects in general…do not suffer such limitations. They more resemble an old farmhouse that grows up room by room, lived in and used throughout construction. Agile encourages modular over monolithic. Adjustments are made like the captain of a sailboat reading the weather and making iterative course corrections all the time. Design is more emergent and pragmatically, the final design may differ significantly from the original plan. The customer and their feedback actually influence the solution approach and THAT, virtually never used to happen with traditional delivery.
When computers were new, the world was changing much slower than it is today. In one human lifetime, we have gone from computers as an anomaly sequestered away in data centers with only a select few users to today’s mobile 24X7 interconnection of most everyone on the planet.
Our world has changed, and as adaptable as people are, our processes have not changed enough to keep up. Agile is an attempt, to help us all rely less on predictability and more on adaptability. It lets us put the customer, and their changing needs at the forefront of design and, done well, relieves some of that tension that has existed between the business & IT.
Have you ever wondered exactly how an SSH key works? What’s it for anyway? Look no further! Let’s get to the bottom of this, shall we?
Here is a breakdown of what an SSH key is and how it can make you feel as free as a baby cheetah running alone in the savanna.
SSH stands for Secure Shell. No, not secure hell. That’s something different. It’s a program that allows you or your app to log into another computer over a network, complete some commands on that computer and then come back your computer with those files.
Simple, right? It’s just like a little messenger that goes back and forth between your server and the remote server.The server will find the public key to give permission back to the user. Public and Private
When an SSH key is generated, it is composed of two sections: public and private, which is exactly what it sounds like.
The public component of the key can be put up anywhere; in fact, it is important that other people know about it. The private component is how you prove to the remote server that you are authorized to perform an action on the remote server.
If it’s not obvious, the private section of the key should never leave your machine—especially if there’s any doubt that it could be compromised in any way. You may create a key with a passphrase on it which will need to be re-entered every time you use it.The Exchange of Info
In order to exchange the info, your app will send a request to a remote server with a list of all the public keys it has access to. The server will find the public key to give permission back to the user. Therefore, you can think of a public key as a lock template that can only be unlocked by the corresponding private key.
The server will generate one of these locks, and send a request with the lock back to the client. The client, assuming it has the private key, will send it back up to the server. This tells the server that the client is allowed to perform actions on the server.Using a (Secret) Agent
An agent is a program that runs on the client so the app doesn’t need to know how any of the process described above works. The secure communication between the server and the app is handled by the agent, rather than by the app itself.
A major benefit of this is that only the agent needs to know how to talk to the server. Your app has no time for this information or drama. It’s like your very mature friend who walks away when the gossip starts flying.
So…the app itself doesn’t have to know the encryption of the keys or even where the keys are! Your app can stay busy minding its own business. You add a key once to the agent, and any app can communicate with that agent on the client; it already has access to all those keys, and you don’t have to add them individually.
Rejoice! Now you know all about SSH. So save your drama for your mama…or your agent.
P.S. GitKraken is a Git GUI client that can generate an SSH key for you automatically. It can even add it to your GitHub account if you give it permission. Since GitKraken uses its own bundled copy of an SSH library, nothing needs to be configured outside of the app. Now that’s really something to rejoice about!
I want to let you know about three great new books on agile you should read. Two of them are in the series I edit for Addison-Wesley; the third is by an author who previously wrote a book for that series.Large-Scale Scrum by Larman and Vodde
“Large-Scale Scrum” by Craig Larman and Bas Vodde is great for anyone looking to scale Scrum up to medium and large projects. It provides a contrast to the very heavyweight Scaled Agile Framework (SAFe), and “Large-Scale Scrum” comes with its own cutesy acronym, LeSS. In fact the subtitle of the book is “More with LeSS.”
The book defines two scaling models. First is standard LeSS, which Larman and Vodde say is typically used for projects with around five teams. It can certainly scale beyond there. But for much larger projects, the book also defines “LeSS Huge,” which the authors report having used on projects with over 1,000 people.
The book is organized as you might expect with chapters devoted to key Scrum topics such as the product owner, the product backlog, sprint planning, reviews and retrospectives, and so on.
I found the book to strike a perfect balance between being overly prescriptive and too general. You’ll leave the book with plenty of advice on how to scale a Scrum project. But you won’t leave feeling hamstrung by having too many rules placed on your teams.
In fact, the authors include a nice summary of LeSS and LeSS Huge rules at the end of the book, and it covers only three pages.Developer Testing by Alexander Tarlinder
Early in my career as a programmer, I remember coming across the phrase, “You can’t test quality in.” I read this inan article that compared 1970s and 1980s U.S. automobile manufacturing to Japanese automobile manufacturing.
The author was saying the U.S. car manufacturers were producing cars of lower quality than their Japanese counterparts because U.S. car manufacturers were trying to test quality into their products. Only after the car was built would they test to see if it was high quality. If it wasn’t, they’d fix defects (say a poorly fitting door) to make the product higher quality.
This was in contrast to Japanese manufacturers who built quality into the process. A later colleague of mine referred to this by saying, “Quality is baked into our process.”
Quality is not something that can be added to a product. Trying to add quality after the product has been built would be like adding baking powder to a cake after the cake has been baked. It doesn’t work.
Alexander Tarlinder’s new book, “Developer Testing: Building Quality into Software,” teaches programmers how to bake or build quality right into the process. The book starts with fundamentals (what is unit testing?) but also delves deep into more advanced topics like testing with mock objects. Similarly, it adds to the debate about testing state vs. behavior.
The book comes in at just under 300 pages, but is encyclopedic in what it covers. This book is a must read for every programmer, even those who are already doing a great job at developer testing.Strategize by Roman Pichler
Most agile processes are empty of any advice on forming a company or product strategy. Product backlogs or featurelists are just assumed to exist or to spring spontaneously from the mind of a product owner or key stakeholder. In his new book, “Strategize,” Roman Pichler fills this void in agile thinking.
Roman is a long-time Scrum trainer based in the UK. He has previously written books about the overall Scrum framework and about succeeding as a product owner.
In “Strategize,” Pichler covers how to form and then validate a strategy, including identifying the right audience for the product and delivering just the features they need. The book covers roadmapping, including addressing the unfortunate misconception that because a team is agile, they don’t need to know where they’re headed.
Pichler presents a very helpful roadmap selection matrix that helps identify what type of roadmap is appropriate for different types of projects. I’ve already put this to use in discussions with clients. And I’m becoming convinced that if a company had a bad experience with roadmapping in the past, it was likely because of doing the wrong type of roadmapping. This book’s roadmap selection matrix will fix that.
This book should be read by anyone involved in determining the future direction for a product or entire organization.What Do You Think?
Which of these books are you going to read next? Or, if you’ve already read any, please share your thoughts in the comments below.
Last week I was out on a hunt deep in the Canadian Rockies. It was remote – really remote. There was no cell service, no wi-fi, no cable TV, no Facebook. On this hunt, I was using the services of a guide. He was a guy in his early twenties – much younger than me. Despite his age, he was very accomplished and seemed to know the area pretty well. We had the usual agreement that you typically make with hunting guides – I pay you in advance for a great hunt, and the assumption is you bag the game you are after, or at least greatly increase the likelyhood of that happening by working with a guide. Implicit in that agreement is that there are no guarantees. Hunting is an unpredictable business (at least the good hunts are) and there is no way to know if you will get your quarry or not. These things aren’t cheap though, so there is a lot of money on the line.
So there is some very real pressure to perform in a situation like this. Expectations are quite high. We were three days into the hunt with no luck yet. That’s not a long time by any means, but the game wasn’t dropping in our lap either. We weren’t seeing much, and the doubts were starting to creep in.
So we set off early in the morning on day four, driving off into the darkness. We pulled over on a nondescript logging road and I followed my guide into the bush. We followed a trail for a while that meandered through meadows and around beaver ponds. We wove in and out of dense thickets of alder and spruce, pausing every once and a while to listen to the wildlife awakening around us. At some point my guide pointed off the trail and said that we should go check out a lake deep in the brush off to one side. I shrugged and followed. After all, he’s the guide. That’s what I was paying him to do. So into the thickets we went.
As we scrambled through the brush, climbing over logs and stumbling through willow thickets, I tried to focus on just keeping up. This young guide was having no difficulty at all moving through these obstacles with relative grace. Meanwhile, this particular middle aged guy seemed to be falling down as often as he was standing back up. I finally caught up with my guide, albeit wheezing mightily.
As we paused and looked around I realized that I had been so intently focused on keeping up with the guide that I had completely lost track of where I was. He had lead me on a merry little journey and I was now totally turned around and completely dependent on him. No problem, that’s why I hired a guide in the first place. He looked around, scuffed the ground with the toe of his boot, and we proceeded onward. Another round of scrambling, more spills and recoveries and 20 minutes later we stop again.
Still no lake.
Huh. This lake was proving to be elusive. With an abashed grin my guide looked at me and said, “We might be a little bit turned around.”
I nodded and told him I certainly couldn’t tell where we were. The sky was a perfectly even overcast grey that eliminated any clue regarding the direction the sun might be in. The nearby mountains, impressive as they were, were actually blocked from view by the thick press of small trees that surrounded us on all sides. So there were actually no major landmarks available to work from. Every direction offered the same information: more trees. My guide headed off again, and I followed.
Now I was starting to wonder, just what does, “We might be a little turned around” really mean? Is my guide lost? He doesn’t look lost. He seems like he knows what he’s doing. What about me? What if he is lost? Can I be of any help? After all, I’m a middle aged hunter who has spent more than a little time in the woods. I’ve been lost before. I know a practical thing or two about survival. I’ve watched the discovery channel. I’m no Bear Grylls, but I should be able to help out, right? So now I’m starting to pay attention to my surroundings. Now I’m starting to ask myself questions like: would I go this direction or is there a better route? Why are we taking this approach? What strategy should we be using to get oriented again.
We reach a clearing and my guide pauses once more. He looks at me with that grin again and says rather apologetically, “I got us completely turned around. I don’t know where the trail is. Or the lake.”
Well there it was. My guide had gotten us lost. My reply, “Yes, I’m afraid I’m lost too. I have no idea which direction the trail is in.” My guide checked in with me – asking if I had been lost in the woods before. I had been, so I wasn’t too freaked out. My mind was racing, I was definitely fully engaged now, but I was not too concerned. If anything I was worried that our little side hike was about to become a big adventure if we couldn’t find our way back to that that trail again.
I found myself in what I think of as “information gathering mode” at this point. What landmarks do I have? Well, we were standing in this little clearing. That’s a landmark, I could establish ordinal directions from the clearing (front, behind, left, right) and I could see a little rise nearby. That’s really all we could see. All other landmarks or clues regarding direction were completely absent. So the first thing that we did was go over and climb the small rise to see if we could see anything from the top.
More trees. So we back tracked in the direction that we had entered the meadow from. We encountered another small open spot in the trees. Now we had a little bit of a map in our heads with the meadow as our basis point. We continued to expand outward from the meadow, and soon, much to our mutual relief, we stumbled upon our original trail that we had begun from. Phew!
As we strolled back to the car I couldn’t help but reflect on the similarity of this experience with some of my recent consulting engagements. In many, hopefully obvious, ways a professional guide is very much like a paid coach or consultant. You have contracted with him to achieve a certain objective: transform your development organization, reach a performance goal, hit a financial target, or shoot a moose. It’s usually something pretty specific. It’s something that you might be able to do on your own, but hopefully by hiring the guide you reduce the risk of failure and bring some assurance of success. That’s what you hire them for. They don’t come with a crystal ball, so they can’t guarantee you success (transformations can fail for many good reasons, moose are fickle creatures that may or may not appear), but nevertheless, you hired them on the explicit premise that indeed they can deliver – make no mistake about that. In fact there is usually significant amounts of money on the line – enough money that you feel some urgency to see success, and the guide feels some urgency to deliver. So the contract we take is very similar.
[Lesson: make sure you know exactly what you are being paid to hunt (protip: “being agile” ain’t it)]
The curious thing for me was the experience from the client point of view. I realized that I gave up any of my own competence and ownership for the outcome to the guide the minute he started to do his job. I was a modestly experienced hunter and outdoorsman, and yet as soon as I hired a guide, I stopped paying attention to the landmarks around me and just started following in the footsteps of the guide in front of me. I’ve experienced this phenomena from the reverse perspective as a consultant in the boardroom too. I’ve had clients look at me and say (almost verbatim), “Tom, you’re the expert. You’ve done this many times before. How should we do X?” These are very capable and quite experienced managers who are putting aside their own expertise and asking for mine. Well, perhaps not putting aside their own experience, but let me put it like this: these are smart, experienced people who are treating me as if I have more experience than they do. Perhaps I do. Maybe I don’t. My guide on that hunt was literally half my age. Yet I was expecting him to lead me on a hunt and achieve a better outcome than someone with twice his age and experience. Admittedly, I didn’t have his experience in the local area, but nevertheless, I was deferring years of expertise to a guide who may or may not have had years of experience in this particular area. In fact, for all I know, I could have been his first client.
[Lesson: your guide may not know more than you do – don’t give up your expertise and competence and follow in their footsteps blindly. As the client, it’s important to keep your wits about you so that you can help assure a successful outcome.]
I’ve found that one of the harder things to do when getting lost is admitting that you are really lost. I remember clearly that feeling of denial as I was following my guide. “Really? We’re lost? Seriously? Are you kidding me? I left my compass in the car? AAaargh!” It’s hard for the client to admit they are lost to begin with, because it’s a threat to their perceived competence – you feel stupid and nobody likes that.
And what about the guide? When you are the guide, admitting that you are lost is crazy hard. Getting lost is probably the one thing the customer is paying you NOT to do. So there is a lot of pressure on a guide to never admit they are lost. But here’s the thing, as a guide you ARE being paid to find something. When the going gets tough you take chances. You look in obscure corners. You go places you haven’t gone before. You experiment. You take risks. You might get a little lost.
So I expect that of my guide. If we are not getting results, I want them to push the envelope a bit. I think many of us do. And with that comes some risk of getting lost. Similarly, organizational transformation can be very disorienting too. As a consultant, it’s terribly easy to get lost in the bewildering forest of people, politics, and technology that you typically find in any given organization of even modest complexity. Let’s face it: there are days when I’m lucky if I can find the restroom.
So I really appreciated the guides honesty with me when he realized that he was lost. That only increased my trust in his ability. As a result, I didn’t get frustrated or upset. I just wanted to get back on track as quickly as possible.
[Lesson: if your guide admits he is lost, it’s a positive reflection of character. Help them get back on track so that you can both be successful again quickly]
The other thing that I noticed was that my guide was pacing himself according to my own abilities. This kid was a veritable mountain goat. He was easily capable of climbing a ridge covered in dense thickets and downed logs without even breaking a sweat. Following him, I felt like I was following an obstacle course designed for American Ninja. He’d be there at the top of the ridge, waiting patiently every time. He was capable of doing much more, but he paced himself according to my own capabilities.
Given his youth and individual capability, he might actually have been able to deliver on the hunt much faster on his own. But when he’s bringing along some middle-aged desk jockey, things are just going to have to go at a slower pace. That’s what a good guide does – he moves at the client’s pace. Maybe he urges them on a bit, but there is a limit. The client may even have unreasonable expectations. For instance, I might like to finish the hunt in a single day, but I’m probably not capable of the physical demands necessary to do that.
In a similar fashion, as a consultant there have been some clients I’ve had who’ve expressed a desire to speed up their transformation. That’s fine unless I’m looking at an organization that is the equivalent of a 80 year old: with slow, brittle processes, a staff resistant to change, riddled with dysfunction. If you try and get them to change too quickly, you risk an organizational heart attack. So you pace things accordingly, because you want them a little winded, not wiped out and gasping for air.
[Lesson: a good guide paces themselves according to the clients capabilities. That implies that the abilities of the client – not the guide, play a large role, perhaps the most important one, in the speed of achieving the objective. A good guide recognizes those limitations and sets expectations accordingly.]
All things considered, it all ended up working out very well. Experiences like this always leave me with a great deal of respect for guides, whether they work in the woods or the silicon jungle. They work extraordinarily hard to try and deliver success for their clients. This guide was putting in nearly 16 hour days with work that was both physically and intellectually demanding. That’s got to be comparable to the amount of time your average millennial in silicon valley puts in behind a desk. OK, I take that back. Maybe it’s not comparable – this guy was working a LOT harder than that. And he had to keep a geek like me entertained. I was really impressed at the kind of dedication he had to the work he was doing. You really have to love it to work that hard. The hunt was a success, and afterward I left feeling like I had a really great guide who had taught me a valuable lesson about being a much better guide for my clients.
Filed under: Agile Tagged: client, consulting, customer, guide, leading, Lost