Node Sentinel File Watcher (NSFW). It’s a file watching module built for Node.js. I built NSFW to overcome an obstacle we were encountering while developing GitKraken, and I released it as an ongoing open-source project. It’s actually entirely safe for work. Ideal for it, even.
NSFW has a file watching implementation for Linux, MacOS, and Windows, which are wrapped and bound for the node runtime to utilize. Thanks to its native implementation, NSFW is able to watch recursive directories on all operating systems in a very performant way.What problem does NSFW solve?
At this time, Node has pretty poor support for file watching. Every operating system has a different capacity to watch directories. Here’s what some celebs have been saying on Twitter:
Linux can’t perform recursive directory watching. MacOS doesn’t provide the filename when a file was changed.
Add to these the fact that there are numerous unsolved issues for Node’s file watcher and that Node does not have a consistent experience across operating systems.How does NSFW solve the problem?
NSFW solves the poor file watching experience on Node by utilizing 3 low-level file watching utilities written in C++ and targeted for the Linux, MacOS, and Windows operating systems.
Linux, MacOS and Windows each ship with their own file watching APIs. Since NSFW’s watch utility is targeted specifically at each of those APIs, it means the experience of using the module is consistent across all three OSs. NSFW fills in the gaps for each API so they’re all consistently feature-complete:
- Linux: The Inotify file watching system does not perform recursive directory watching, so NSFW builds and maintains a recursive watch tree for you.
- MacOS: FSEvents is known to produce inconsistent file events (the file event bitmask becomes corrupted if events occur too quickly), so NSFW stats and disambiguates file change events for you.
- Windows: supports all targeted needs out of the box. (RECORD SCRATCH) That’s right, Windows has the best native support. I said it.
GitKraken is currently the primary consumer of NSFW. A good Git client should not ship with a refresh button because it should automatically know when things change.What could have been: Imagine if GitKraken needed a refresh button like this. Gross!
NSFW is essential to the smooth, cross-platform experience of GitKraken, as it helps the app respond quickly and accurately to changes in a repository it is viewing. NSFW is a quiet and humble, no-frills background process. It doesn’t make waves. It doesn’t talk through movies, chew loudly or snore, but its transparency is its strength; if you notice it, it’s more than likely because something isn’t working. So cheers to watching files silently and effectively – something made easy by the NSFW module.Development hurdles
With no experience in any of the file watching APIs, little experience in the Native Abstractions for Node (NAN) API, and no clear understanding of how to model the interactions Node makes with each file watching utility, the 0.x.x NSFW releases were, umm, troubled.
On Windows, I tried using C++/CLI to use the fancier file watching module provided by the .NET library. While this made it quick to get up and running, it inevitably backfired, because some users were unable to run GitKraken due to missing library dependencies. Sigh.
I also encountered strange errors related to having two distinct garbage collectors running concurrently (one for Node and one for the managed file watcher). When I scrapped the .NET implementation, I achieved much stronger stability for the Windows operating system.
On Linux and MacOS, issues revolved around unfamiliarity with the file watching API and native constructs. The overall unfamiliarity combined with the different strategies each operating system incorporated, ended up turning the entire project into a spaghetti turd. [REDACTED: DEEMED NSFW BY THE AXOSOFT DEPARTMENT OF PROPAGANDA]
Finally, large file change operations slowed down every operating system. At the time, those messages had no throttling behavior. The Node application would get absolutely hammered by file system change notifications and slow to a crawl. We suffered the consequences of that in GitKraken whenever we walked through our bootstrap process, which involves a lot of file manipulation.
After fiddling around with the project through the 0.x.x months (aka The Dark Times), I learned a lot about how each underlying file watcher API works, including their caveats, demands, and broken bits.
After spending a week putting together a complete system diagram, I scrapped the entire 0.x.x project and rebuilt the project to handle the differences of each operating system in a planned way. I also did away with the C++/CLI interface and opted for ReadDirectoryChangesW in Windows.A couple of lessons learned
- Predicting a system’s architecture without first dirtying your hands with the core features, means you’ll probably end up throwing away your project, dirtying your hands with the core features, and starting the project over. As a new developer, be prepared to throw away your prototypes.
- I’m not sure if C++/CLI and Node should ever be a thing. Ever.
Scheduling Your Energy, Not Your Time By Scott AdamsYes that Scott Adams!
In that short article Scott give you his secret to success - it's basically free. Now you could go out and buy a book like one of these to get other advice about your time usage. Or - you could start by taking his (free) advice ... the decision is yours; but it's past time to make it.
The Time Of Your Life | RPM Life Management System $395 by Tony Robbins
100 Time Savers (2016 Edition) [obviously time sensitive information]Tell Your Time: How to Manage Your Schedule So You Can Live Free by Amy Lynn Andrews
I'm Dysfunctional, You're Dysfunctional by Wendy Kaminer. "The book is a strong critique of the self-help movement, and focuses criticism on other books on the subject matter, including topics of codependency and twelve-step programs. The author addresses the social implications of a society engaged in these types of solutions to their problems, and argues that they foster passivity, social isolation, and attitudes contrary to democracy."
It’s that time of year again. Whether this is a time of lavish attention for you, a time of dread and low self-esteem, or merely an opportunity for you to shake your fist at the cynical commodification of love and affection, we can all agree on one thing: It’s Valentine’s Day, sweetie.
And what greater gift could be bestowed on this most romantic of occasions than a new version release of your favorite Git client, GitKraken?
As usual, you can check out our release notes for the detailed breakdown of what’s new, but here’s a quick summary of what you can enjoy from this most salacious of software updates.Remote Avatars
It’s always good to put a face to a name, and your remotes are no exception. In a major quality-of-life update, GitKraken now displays your cute remote avatars right in the graph. Doesn’t sound like a big deal, lover? Try having a bunch of refs in your graph and quickly distinguishing between them, honey. Prior to v2.1, this was an obstruction to the efficiency of the app.
As of version 2.1, you can quickly and easily see whose remotes are where, with those remotes being visually identifiable at a glance. (Please note that we can’t vouch for the aesthetic quality of your team members’ avatar choices, though. We’re good, but there are some things we just can’t fix, sugar.
One of the foundational principles of agile and Scrum is a belief in the power of self-organizing teams. This makes a micromanaging boss, ScrumMaster or product owner a particularly difficult problem for agile teams.
I’ve found asking three questions helpful in dealing with micromanagers.Who?
The first question is Who? Who is being micromanaged? If you are being micromanaged but the rest of the team is not, this tells you it is your own performance that someone is worried about. If so, you’ll need to improve your own performance and that stakeholder’s view of your performance.
But if your entire team is being micromanaged, the behavior is just part of who that stakeholder is.
To determine whether it’s just you or your entire team being micromanaged, spend a sprint or two noting what types of things draw the micromanager’s attention. Log all micromanaging activities so you can look back at the data and determine who is being micromanaged.When?
A log of micromanagement activity will also help you answer the second question: When is the micromanaging occurring?
Does the stakeholder micromanage shortly before or after a meeting? For example, a product owner might leave their customer call every Tuesday feeling stressed and more inclined to micromanage. Or a Scrum Master might be prone to micromanage the day before the monthly meeting with the engineering VP.
Some people are more prone to micromanage at a specific time of day. A boss early in my career was particularly prone to micromanaging before his first cup of coffee.
Others may be more prone to micromanagement at specific times during an iteration. Perhaps the person you’re dealing with is most prone to micromanaging during the last few days of the iteration when he or she gets nervous about whether everything will get done. Again, log this type of information so you can later look for patterns.
I use a spreadsheet with the following columns:
Date: The actual date (e.g., March 8, 2017). This usually won’t help identify patterns but can be useful if you look back on the data and need to remember what might have been going on in the organization at the time.
Day of Week: Sometimes micromanaging occurs most frequently on certain days (e.g. Friday) so note the day of the week.
Day of the Sprint: To help see if micromanaging occurs most frequently at certain points within a sprint, note the number of days into the sprint when the micromanaging occurred. For example “Day 3” or perhaps “7 / 10” to indicate it occurred on day seven of a ten-day sprint.
Time: Note the time of day when the micromanaging occurred (e.g., 10:15 A.M.)
Who Was Being Micromanaged: Note whether it was you personally, the entire team, or perhaps a teammate being micromanaged.
What Was Being Micromanaged: Note the issue in this column.
Context: Note whether the micromanaging coincided with anything else occurring within the sprint, project or organization. Did it occur right before or after a meeting? Which meeting? What was occurring during the iteration overall?
Notes: Include anything additional worth remembering about the incident. You can see a sample in the following table.
Sprint Time Micromanager Who? What? Context Notes March 8 Wed 6
10:30Anne me Story about adding data sources
Anne asked me for the 3rd time in two days how this was going.
March 8Wed 6 2:15 Arie team Next week’s new client launch
Arie emailed the full team to remind everyone how important the new client launch is
Story about Salesforce integration
While en route to daily scrum, Anne asked me to tell Ashishto see her sometime about the story he’s working on for her.
Ashish has been providing her a daily update already as she requested.
After you’ve logged a couple of weeks of micromanaging activities, it’s time to ask the third question: Why is the micromanaging happening?
Scan your log looking for patterns. See if there are triggers that create the micromanagement. Perhaps your product owner micromanages you after her weekly meeting with her boss.
Perhaps your line manager is prone to micromanaging at the end of the month when he has to prepare a report for his boss.
Based on the patterns you see, try to identify conversations that may be worth having with whoever is micromanaging. You’re unlikely to get far by merely saying, “Please stop micromanaging.” Instead, talk to micromanagers in an attempt to learn what concerns them that they’re behaving as they are.
Once you’ve identified some of the triggers for micromanaging, it’s time to anticipate and eliminate those triggers.Anticipate and Eliminate
If you can anticipate micromanaging behavior by noticing when it occurs, work to eliminate the trigger. Often you can do this by proactively providing information to the micromanager.
For example, if you know your product owner gets stressed and micromanages after a weekly meeting with her boss, schedule a meeting with your product owner ahead of that meeting. Be sure your product owner is well informed and prepared for her meeting.
Proactively provide information to stakeholders who are prone to micromanagement. Try to do it just in time so they have (and remember) the information in advance of whatever triggers them.
Avoid creating burdensome new processes for yourself. But you can assert control over a stakeholder (or boss) relationship by proactively providing information rather than waiting to be asked for it and then being forced to provide it on someone else’s schedule.Some People Are Incurable
By following the advice here, you won’t always be able to eliminate micromanagement. Some stakeholders are incurable micromanagers. But the tips here will help you take greater control over most situations and generally make them more tolerable.How Have You Handled a Micromanager?
What’s your worst story of being micromanaged? How did you handle the situation? Please leave your thoughts in the comments below.
Get Your Free Micromanagement Log
Start tracking to help eliminate micromanagement
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
“I have an existential map. It has ‘You are here’ written all over it.”
I happened to be in a cabin one evening after a long day of hunting. The wood stove was blazing and we were all chilling after dinner. The guides were off to one side hanging out together sharing their experiences from the day. It was fun to watch them as they described where they had been and what they had seen. The dialog would go something like this:
“We were down trail X off of the old logging road Y near the fork in the road and we didn’t see anything”
“You mean down past road Z near the bridge, right?”
“No, no, no. We were down logging road Y.”
Around and around they went.
At this point in the conversation they usually resort to hand gestures to further supplement the conversation. This goes on for a while and pretty soon it’s hard to tell whether you are looking at guides trying to tell each other where they were, or perhaps you are looking at a pair of fighter pilots describing their latest dogfight. There are hands waving wildly in the air. It’s Top Gun in the hunting cabin. Voices are raised, and expressions are animated.
And still they can’t seem to simply tell each other where they were. I’m watching all of this and I’m thinking, “These guys need a map.”
I’d laugh, but I see it all the time in software teams. If I’m honest, I catch myself doing it all the time. It seems that even with all the software that we have today, visualizing what we do and sharing it with each other is still a significant problem for us. How often do you find teams working together and trying to describe something – hands waving in the air and all. I guess we’re all future fighter pilots.
Like I said, I think sometimes what we really need is a map. I challenge you to go take a look at the walls in a second grade classroom. You’ll see nothing but maps. Maps of the US. Maps of the parts of a sentence. Maps of numbers. Everywhere there are maps of the knowledge that second graders consider important. What you see on those walls is the cartography of the eight year old mind.
Now go back to your office and look at the walls. What do you see? I’m betting that the walls are completely bare. Maybe you have some of those crappy motivational posters. If you are really lucky there is a map to the fire escape. There are no maps in the office of the typical knowledge worker. Why is that?
All too often we are like the guides in the cabin. We’re struggling to communicate simple concepts with each other – playing Top Gun. Maybe it’s time for a map.
Filed under: Agile, Teams Tagged: cartography, communication, knowledge work, maps, Software, Teams
My most recent post about how to Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban.
I use paper. Here’s why I don’t use a tool:
- I am too likely to put too much into a tool. I put all this week’s work, next week’s work, next month’s and next year’s work, even though I’m not going to think about anything that far out. Paper helps me contain my To Do list.
- When I collaborate with others, they want to break down the stories (large as they may be) into tasks. No!! I can’t take tasks. I need to see the value. See my post about From Tasks to Stories with Value.
- I change my board, depending on what’s going on. I often have a week-based kanban because I retrospect at the end of the week. I often—not always—have a “today” column.
This is what my board looks like this week. it might look like this for a while because I’m trying to finish a book. (I have several more books planned, so yes, I will have a bunch of work “in progress” for the next several months/rest of the year.)
I have several chapters in This Week. I have two chapters in “Today:” That helps me focus on the work I want to finish this week and today. As a technical editor for agileconnection.com and as a shepherd for XP 2017, I have work in “Waiting to Discuss.” I will discuss other people’s writing.
Earlier this week, I had interactions with a potential client, so that work is now in Waiting for Feedback. Sometimes, I have book chapters there, if I need to discuss what the heck goes in there and doesn’t go in a chapter.
I haven’t finished much yet this week. I am quite close on two chapters, which I expect to finish today. My acceptance criteria is ready for my editor to read. I do not expect them to be done as in publishable. I’ll do that after I receive editorial feedback.
Could I do this on an electronic board? Of course.
However, I limit my WIP by staying with paper. I can’t add any more to the paper.
Should I have WIP limits? Maybe. If I worked on a project, I would definitely have WIP limits. However, the fact that I use paper limits what I can add to my board. If I notice I have work building up in any of the Waiting columns, I can ask myself: What can I do to move those puppies to Done before I take something off the Today or To Do columns?
I’ve been using personal kanban inside one-week iterations since I read Benson’s and Barry’s book, Personal Kanban. (See my book review, Book Review: Personal Kanban: Mapping Work | Navigating Life.
You should use whatever you want as a tool. Me, I’m sticking with paper for now. I don’t measure my cycle time or lead time, which are good reasons to use an electronic board. I also don’t measure my cumulative flow, which is another reason to use a board.
I do recommend that until you know what your flow is, you use paper. And, if you realize you need to change your flow, return to paper until you really understand your flow. You don’t need a gazillion columns, which is easy to do in a tool. Use the fewest number of columns that help you achieve control over your work nad provide you the information you need.
Question for you: Do you want to see a parking lot board? I have images of these in Manage Your Project Portfolio, but you might want to see my parking lot board. Let me know.
Most people I know—even the people supposedly using agile—have too much work to do. You have project work. You have support work, formal for customer support or sales, and informal for your colleagues. You have reports to write or file, time cards to fill out, or other periodic events.
You need a way to say no to more work.
I wrote an article for Better Software, which is now online. See Saying No to More Work. (You need to register for the site to see the article. No charge for registration.)
One person wanted to see the kanban boards I referred to in the article. I am happy to show them to you here.
These are two potential kanban boards. The one on the left is the basic personal kanban board. Note that there are no WIP (Work in Progress) limits (yet) on this board. I would add WIP limits. Especially if I wanted to convince my manager I was doing too much work.
On the right, you can see a disaster of a personal kanban board. There are many items To Do, three in Progress and a total of six stuck in various Waiting states. Yes, I had a board that looked like this many years ago. Then, I made a picture on a piece of paper and explained to my boss I was just one person. What did he want me to do and not do?
Now, given what I know, I would add WIP limits to each column.
If you want to see the project portfolio images for how I start at the organization level: the calendar view and kanban view, see Manage Your Project Portfolio at the Prags. At the end of the blurb, there’s a link to the quick start guide, which has just two of the images in the book. (I included many possible ways to visualize the project portfolio in this edition of the book.)
Here’s the key idea: Don’t take on more work than you can complete in a reasonable amount of time. Don’t multitask. Instead, see what your work is and how you might discuss it with your manager.
Last week, in response to the executive order banning entry of refugees and visa holders from seven countries into the US, Axosoft Founder Hamid Shojaee announced that Axosoft would be donating 100% of GitKraken Pro revenues to the American Civil Liberties Union (ACLU), over the course of 3 days.
We were not alone in taking a stance against what many have been calling the ‘immigration ban’. Multiple prominent executives of tech companies have also shown their support by offering to match donations to the ACLU: Stripe CEO Patrick Collison, Nest founder Tony Fadell, Slack CEO Stewart Butterfield, and Facebook’s head of advertising Andrew Bosworth, just to name a few.
Thanks to tech executives and nearly 1 million people who have made online donations, the ACLU has received over $79 million in new contributions since the election. We’re happy to announce that we’ll be adding another $17,030 to that total!
The ACLU is using these donations to continue its 97-year-long battle for justice, equality, and democracy. The ACLU has even been accepted into the winter batch of companies enrolled in top Silicon Valley startup accelerator Y Combinator. The nonprofit will receive mentorship and guidance on how to best utilize donations to grow the organization and its infrastructure.
I remember when 3D printers were first becoming accessible to everyday makers. One of the new printers touted its ability to replicate itself by printing parts that could make another 3D printer which could print parts for another 3D printer, and so on.
This recursive concept was really interesting, and something I thought about when we were asked this question in one of our recent GitKraken community Slack AMAs:
“Do you manage GK source code completely from GK? If so, how long did it take to be self-sufficient?”
Just like those self-replicating 3D printers, we do in fact use GitKraken to make GitKraken and have been doing so since around version 0.0.3, when it was just a tiny baby Kraken. Using only GitKraken, even in its infant state, was an important exercise that helped ensure we were including features that developers actually needed. It helped us to constantly improve the user experience with each release—because a “powerful” tool that is awful to use isn’t much good to anyone.
If you’ve ever wondered how developers use their own tools that make those same tools, allow me to give you a bit of insight into our process, and show you how GitKraken is vital to its own creation. In this existential journey, you’ll learn how GitKraken devs use GitKraken to make GitKraken.
Imagine you are new to the GitKraken team and eager to start contributing to development. You have a GitHub account right? You do. Everybody has a GitHub account (how do you think grandma submits pull requests to the Linux repo?). So, we would give you access to the GitKraken repository on GitHub (lucky you!) where you would fork your own copy of the GitKraken source code. This is important because it gives you your own safe sandbox to play in without breaking the production version of GitKraken.
Equipped with a safe repo with which to experiment, you’d download and install your own copy of GitKraken, skipping the task of installing Git altogether if you so choose. Then, since you’re working on a GitHub hosted repo, you’ll want to take advantage of GitKraken’s powerful GitHub integration by signing in with your GitHub account. This allows GitKraken and GitHub to talk with one another in a seamless way.Simple sign-in with GitHub account
You’ll get a glimpse of the power when you go to clone the GitKraken repo. Instead of going back to GitHub to get a clone URL, just pop into the GitHub tab in the Clone menu, and search for the repository you want to clone. Because you’ve connected GitKraken with GitHub, all the repos you have access to will be searchable in GitKraken for easy cloning.Cloning with GitHub integration
With your repository cloned and opened in GitKraken, you’ll have a local version on your machine and a remote connection (origin) already set up to the main GitKraken repository on GitHub. Remember that fork you made on GitHub? You’re going to add that as a remote, using that slick GitHub integration, to find your repo on GitHub instead of leaving GitKraken.Adding another remote New squid-chan remote
All GitKraken developers work from their own forks of GitKraken. Adding those as remotes in GitKraken gives us an overview of who is working on what, and makes it easy to check out someone else’s branch to collaborate with them or review their work. We can also hide the remotes we don’t need to see, keeping the graph tidy. This reduces the number of auto fetches that occur to keep everything up-to-date. Hidden remotes can still be fetched manually from the context menu with a right-click.Viewing and hiding other team members’ remotes
Having personal forks of GitKraken makes creating pull requests (PRs) on GitHub even easier thanks to drag-and-drop actions in the left panel. Most of our work is merged into development first for review and testing before it is included in a staging build. When a developer has finished working on a branch, that gets pushed to their remote where it can be dragged and dropped onto origin/development to start a PR from GitKraken.Drag-and-drop to start a PR on GitHub
GitKraken’s GitHub integration continues to save time in our workflow by allowing us to open a PR with all of the relevant information pre-filled in a simple form. All we need to do is add a basic title and description then submit it to GitHub. For more detailed editing, the PR can be easily opened in GitHub directly from GitKraken.Creating a pull request on GitHub from GitKraken
After pull requests are created, we assign developers to review them using GitHub’s pull request review system. In GitKraken, we keep track of open PRs in the left panel and can easily open them in GitHub to review.
Upon approval, a mysterious DevOps process occurs that merges that PR into development, which is used for staging builds for QA to check, and eventually a shiny new release is bestowed upon the world for all to enjoy. Pulling back the curtain on that is an article for another day.
I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight.
I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur:
- The technical people see the work they want to accomplish. They create a list of tasks to get there: design database, create infrastructure, fix these typos in the UI, and more.
- Or, someone (such as an architect) is in charge of breaking down work, not team members. That person creates tasks.
- Marketing or sales (or someone not in the product development team) says something like this: “I want a drop-down menu,” or a radio button or another report. They don’t remember to explain who the value is for, or why they want that value. Pretty soon, the idea of value is gone altogether, and only tasks remain.
- Teams start to create stories, and the stories are so large, they create tasks to cover the stories. Pretty soon, they stop creating stories at all. They only create tasks.
Here’s a gotcha: When teams measure story points as opposed to features, they often feel pressure from management to do more points. (See Who’s Playing Agile Schedule Games?)
Your customers don’t buy points. They buy completed features.
Something clicked for the participant last week. He saw the feature chart, which explains how scope expands during the project and what the team(s) delivers.
This chart shows the features complete, added, and remaining to do. Because it measures features—what customers buy and use—there’s no confusion about work done or not done. Plenty of work might be done. But, if the work doesn’t add to a feature, the work is inventory (or possibly waste).
Here’s one value of this chart: Until tasks add up to features, you don’t count them.
My participant couldn’t articulate the problems before. The chart helped him see and discuss:
- Tasks—by themselves—might not add up to a feature. He wants features.
- When he counts features, he can describe what’s in a feature set—a collection of features that you might call an epic or a theme.
- He can explain why he wants just this small feature, and not necessarily all of a feature set for now.
The chart helped him see how to separate stories and count them. He is moving from tasks and technical stories to features, real user stories.
I use this chart with cumulative flow diagrams and the product backlog burnup chart to see where our work is and how much progress we make over time for a given feature set.
I recommend you build and count features (stories). The smaller you can make a story, the faster you can get feedback and see the value in it.
If you’re interested in this workshop, I have just announced the May 2017 dates. See Practical Product Owner Workshop: Deliver What Your Customers Value and Need.
Is it done, is it done done, or is it done done done?
I bet you’ve asked that question before, if you are in the business of application development. When asking the questions, it is important to note who you are and your level in the organization. Delivery teams, program teams, and portfolio teams define done differently. For certain, we need is a clear definition of done at each level of the organization.Definition of Done
The definition of done (DoD) is when all conditions (acceptance criteria) that a software product must satisfy are met, to be accepted by a user, customer, team, or consuming system. We must meet the definition of done to ensure quality. It lowers rework, by preventing user stories not meeting the definition from being promoted to higher level environments. It will prevent features not meeting the definition from being delivered to the customer or user.User Stories
The most common use of Definition of Done is on the delivery team level. Done on this level means the Product Owner reviewed and accepted the user story. Once accepted, the done user story will contributed to the team velocity. Meet all of the defined criteria or the user story is not done.
The below examples might be included in the User Story DoD:
- Unit tests passed
- Code reviewed
- Acceptance criteria met
- Functional Tests passed
- Non-Functional requirements met
- Product Owner accepts the User Story
Done on this level may mean it qualifies to add to a release. Not all user stories need to be completed. Rather, it means the feature may be sufficient to satisfy the need. Once accepted, the done feature will contribute to the release velocity. Meet all of the defined criteria or the feature is not done.
The below examples might be included in the Feature DoD:
- Acceptance criteria met
- Integrated into a clean build
- Promoted to higher level environment
- Automated regression tests pass
- Feature level functional tests passed
- Non-Functional requirements met
- Meets compliance requirements
- Functionality documented in necessary user user documentation
Done on this level may refer to a organizational strategic priority, portfolio plan item, or some other collection of features that satisfied a market need. Not all user stories or features need to be completed. Rather, the epic may be sufficient to satisfy the need. Once accepted, the done epic will contribute to throughput calculations to see if the supply is in balance with demand.
The below examples might be included in the Epic DoD:
- Non-Functional requirements met
- End-to-end integration completed
- Regression tests pass
- Promoted to production environment
- Meets defined market expectations
Just as the definition of ready is super important, so is the definition of done. Never start work on something until you have agreed on the definition. Be consistent. Be clear. Have a shared understanding.
Is your agile transition proceeding well? Or, is it stuck in places? Maybe the teams aren’t improving. Maybe no one knows “how to get it all done.” Maybe you’re tired and don’t know how you’ll find the energy to continue. Or, you can’t understand how to engage your management or their management in creating an agile culture?
You are the kind of person who would benefit from the Influential Agile Leader event in Toronto, May 9-10, 2017.
Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your specific business challenges.
If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us.
We sold out of super early bird registration. Our early bird registration is still a steal.
If you have questions, please post a comment or email me. Hope to work with you at The Influential Agile Leader.