Alexey Krivitsky recently posted a presentation on his blog, agiletrainings.eu, addressing the issue of so-called-agile tools, specifically Jira.
Here is a link to his presentation.
The movie images he chose gave me a chuckle and his points really hit home.
He offers 4 points to what he calls a “Jira Rehab Program” and I found the points interesting.
Take a look. See what you think.
Share your comments on your experience with agile tools here.
Have you had success with Jira or would you rather see it disposed of?
And check out Mishkin’s recent article on the ideal electronic Agile tool.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
One of the positive outcomes of an agile team succeeding in its transformation is the establishment of a high-functioning team.
A high-functioning team works more effectively, efficiently and can innovate more appropriately for the corporate advantage of the business.
Ryan Yeoman has a lot to say on the topic. Although he doesn’t mention agile specifically, he’s right on in his approach.
In his article, “Strong Teams Start With Trust: 5 Ways To Build Trust in Your Teams,” he writes that:
All of them point to trust as a critical and fundamental piece to success – in business and in life.
Piggy-backing all these thoughts and making it personal to myself, trust enables me to be more. It enables me to:
- Accomplish more and do better work by getting feedback and synergizing
- Grow and learn more by allowing myself to be “open” and receive information
- Teach more and serve by letting me focus my attention on others
- Care more and empathize because I’m not constantly worried about protecting myself
- Be more human
Trust helps you accept deepening relationships and removes politics and silos from the work place, creating an organization within which people feel safe. At its simplest, trust is a catalyst for your organization to be more: more nimble, more efficient, more effective. It’s like oxygen for a successful team – one simply can’t exist without it.
I found his comments insightful and his links appropriate.
This is an excellent article for those team members who are striving for excellence and learning to trust one another, and themselves, in the process.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Over the last week I’ve spent a little bit of time playing around with the data in the Kaggle TalkingData Mobile User Demographics competition, and came across a notebook written by dune_dweller showing how to run a logistic regression algorithm on the dataset.
I’ve not used it before so I created a small example to get to grips with it.
Let’s say we have 3 rows to predict and we happen to know that they should be labelled ‘bam’, ‘spam’, and ‘ham’ respectively:
>>> actual_labels = ["bam", "ham", "spam"]
To work out the log loss score we need to make a prediction for what we think each label actually is. We do this by passing an array containing a probability between 0-1 for each label
e.g. if we think the first label is definitely ‘bam’ then we’d pass [1, 0, 0], whereas if we thought it had a 50-50 chance of being ‘bam’ or ‘spam’ then we might pass [0.5, 0, 0.5]. As far as I can tell the values get sorted into (alphabetical) order so we need to provide our predictions in the same order.
Let’s give it a try. First we’ll import the function:
>>> from sklearn.metrics import log_loss
Now let’s see what score we get if we make a perfect prediction:
>>> log_loss(actual_labels, [[1, 0, 0], [0, 1, 0], [0, 0, 1]]) 2.1094237467877998e-15
What about if we make a completely wrong prediction?
>>> log_loss(actual_labels, [[0, 0, 1], [1, 0, 0], [0, 1, 0]]) 34.538776394910684
We can reverse engineer this score to work out the probability that we’ve predicted the correct class.
If we look at the case where the average log loss exceeds 1, it is when log(pij) < -1 when i is the true class. This means that the predicted probability for that given class would be less than exp(-1) or around 0.368. So, seeing a log loss greater than one can be expected in the cass that that your model only gives less than a 36% probability estimate for the correct class.
This is the formula of logloss:
In which yij is 1 for the correct class and 0 for other classes and pij is the probability assigned for that class.
The interesting thing about this formula is that we only care about the correct class. The yij value of 0 cancels out the wrong classes.
In our two examples so far we actually already know the probability estimate for the correct class – 100% in the first case and 0% in the second case, but we can plug in the numbers to check we end up with the same result.
First we need to work out what value would have been passed to the log function which is easy in this case. The value of yij is
# every prediction exactly right >>> math.log(1) 0.0 >>> math.exp(0) 1.0
# every prediction completely wrong >>> math.log(0.000000001) -20.72326583694641 >>> math.exp(-20.72326583694641) 1.0000000000000007e-09
I used a really small value instead of 0 in the second example because math.log(0) trends towards negative infinity.
Let’s try another example where we have less certainty:
>>> print log_loss(actual_labels, [[0.8, 0.1, 0.1], [0.3, 0.6, 0.1], [0.15, 0.15, 0.7]]) 0.363548039673
We’ll have to do a bit more work to figure out what value was being passed to the log function this time, but not too much. This is roughly the calculation being performed:
# 0.363548039673 = -1/3 * (log(0.8) + log(0.6) + log(0.7) >>> print log_loss(actual_labels, [[0.8, 0.1, 0.1], [0.3, 0.6, 0.1], [0.15, 0.15, 0.7]]) 0.363548039673
In this case, on average our probability estimate would be:
# we put in the negative value since we multiplied by -1/N >>> math.exp(-0.363548039673) 0.6952053289772744
We had 60%, 70%, and 80% accuracy for our 3 labels so an overall probability of 69.5% seems about right.
One more example. This time we’ll make one more very certain (90%) prediction for ‘spam’:
>>> print log_loss(["bam", "ham", "spam", "spam"], [[0.8, 0.1, 0.1], [0.3, 0.6, 0.1], [0.15, 0.15, 0.7], [0.05, 0.05, 0.9]]) 0.299001158669 >>> math.exp(-0.299001158669) 0.741558550213609
74% accuracy overall, sounds about right!
This video introduces some key features to the thinking behind real agility.
80 % = 90% of money and resources in an organization is going to waste and only 10% – 20% goes to productive, valuable work.
Real agility helps to solve this problem by creating a state where the amount of waste is reduced and the about of productivity is increased.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
What’s a Spike? Who should create it? And what should it look like in VersionOne? (Or in Agile Central, Pivotal Tracker, HP AGM, Jira, or your ALM tool.)
Excellent questions! I thought I’d share my thoughts on the topic:What’s a Spike?
Sometimes a story is too large or overly complex. Perhaps the implementation or a 3rd party tool or library is poorly understood. The team can’t estimate the story. Perhaps we’re unsure if we’ll be able to complete the story due to some potential blocker.
In these cases, we might want to build a functional or technical experiment to figure it out. We might want to look into something for a day. We might want to look up alternatives. Do some googling. Do an experiment with some other library or software package. Consider alternative refactoring paths.
These are “spikes”. You can call them research spikes, or architectural spikes, or refactoring spikes if you wish.
A spike as an investment the Product Owner makes to figure out what needs to be built and how the team is going to build it — in advance of actually building it. The Product Owner allocates a little bit of the team’s capacity now, ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.
Therefore, a spike is an investment to make the story estimable or schedule-able.Spikes Represent Risk
Here’s the deal with spikes though… spikes represent risk. Spikes represent uncertainty. If our backlog is full of spikes, that means that our backlog is full of stuff we don’t know how to do. If our backlog is full of stuff we don’t know how to do, our product delivery process isn’t going to be stable. It means that we have no business making commitments at the release level, because we don’t have a credible plan for getting to done.
Therefore, you generally don’t want spikes to hang around very long. I usually try to do them about as soon as I discover the need for it. I usually stick it in the next sprint, if I can’t add it to this sprint.How to Enter a Spike
If the spike only takes, say, an hour or two, maybe we don’t need to track it in our ALM tool. If it’s larger than that, you should enter it into your backlog.
How would a BA or Product Owner write up a spike? The cocky answer is to say “make your tech lead enter it”. A more serious answer would be that the technical story format would be good:
In order to <achieve some goal> <a system or persona> needs to <some action>.
Example: In order to split the collection curve wizard story, the tech lead needs to do some detailed design. (Just enough to split the story.)
Example: In order to estimate the “user connection report” story, the tech lead and BA need to research capabilities of MSTR and have some conversations with the PO. (Just enough to estimate the story.)
I like to start the name or title with “SPIKE:” to make them stand out in the ALM tool. Using a tag or a label could work as well.Time-box your Spikes
Teams should agree that every spike is, say, never more than 1 day of research. (For some teams this might be, say, 3 days, if that’s the common situation.) At the end of the time-box, you have to report out your findings. That might result in another spike, but time-box the experiments. If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next. What to do next might be to define another spike.
You might say “I think there’s a bug in the app server… there’s no way I can hear back from their support within the time-box.” The timebox is effort, not calendar time. So, the spike can be about recreating the problem and providing enough info for the support group to look into it.
It’s also best if a spike has one very clear question to answer. Not a bunch of questions or an ambiguous statement of stuff you need to look into. Therefore, split your spikes just as you would large user stories.
You don’t have to use the whole time-box. For example, if it’s an estimate that you were after, do just enough work to give the estimate and stop.
By the way, I don’t estimate spikes, but that’s another blog post.
There you have it, an answer to what’s a spike. More than you ever wanted to know about spikes!
The post What’s a spike, who should enter it, and how to word it? appeared first on LeadingAgile.
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
If you look at the latest Chrome, Safari, Firefox and MS Edge browsers, you’ll notice the compatibility and feature implementation of ES6 is darn near complete.
And for the majority of developers that still have to support older browsers? Babel and other pre-compilers have you covered.
There’s so much adoption among the latest browser versions, the latest node.js, and pre-compilers, that you don’t have much reason to ignore ES6 moving forward.
But what does this mean for some of the old stand-by libraries that have not only provided great APIs and utilities, but also helped to define the feature set in ES6?
Tools like underscore and Lodash – are they now obsolete, with ES6 features replacing most of the utility belt that they had provided?I have to admit – I rarely use underscore or Lodash anymore.
Other than my front-end code where I am still stuck in my Backbone / Marionette ways, I’m rarely installing underscore or Lodash into my projects, intentionally.
Every now and then I see enough need to install one of them. But, more often than not I turn to the ES5 and ES6 counterparts for the methods that I use frequently.
For example, some underscore -> es5/es6 array methods:
- each -> forEach
- map -> map
- reduce -> reduce
- find -> find
- filter -> filter
- contains -> includes
- etc, etc, etc
While the method signatures and behavior are not 100% the same, there is an unmistakable influence in the ES5/ES6 list of array methods, compared to the underscore and Lodash API.
Because of this, I have largely been able to do without these utility belts.But I wondered if I was the exception or the rule.
I knew that my use of these libraries was limited compared to a lot of people.
I had assumptions about this, because of my own experience. But, I wanted to verify that my thoughts on “underscore is dead” were shared in the community.
So I sent out a poll on Twitter and asked,Are you still using Lodash / underscore?
are you still using underscore / Lodash, now that ES2015 is available most places / with precompilers?
— Derick Bailey (@derickbailey)
The results shown in the poll were nothing like my own experience and expectations.
Only 9% of the 236 responses said that ES6 (ES2015) makes Lodash / underscore obsolete.
Personally, I fell into the 17% of “yes, but rarely”.
But the overwhelming majority of respondents – nearly 75% of them – said they still use these libraries frequently, with nearly half the responses wondering they they wouldn’t use them.
With the responses pouring in, I had to know why. So I asked a follow-up question.Why are you still using Lodash / underscore?
if you said yes, you are using underscore / Lodash still, what features / methods, and why?
— Derick Bailey (@derickbailey)
The responses were generally categorized into two things:
- Methods on objects, instead of just Arrays
- Functional / composition based coding
For example, there are a lot of methods in the ES5/6 Array object that can be applied to Objects, with these libraries.
@derickbailey AFAIK, es5 map/reduce/filter only work on arrays
— Sean Corrales (@seancorrales)
@derickbailey _.pick/omit, _.map for objects, _.isX, _.indexBy, _.sortBy, _.escape, _.debounce/throttle … I could keep going.
— Ben Vinegar (@bentlegen)
With the rise of functional programming, it’s also not surprising to see many people using these libraries in that paradigm.
@derickbailey Using Lodash/fp on almost all projects at work.
— Cyril Silverman (@CyrilSilverman)
@derickbailey also ES2015 didn’t added so much worth to me since I don’t use `this` and `prototype`-stuff. rest and spread are interesting.
— Stephan Hoyer (@cmx66)
And if you’re using these libraries already, might it be easier to use them everywhere instead of trying to remember which methods are built-in and which come from the library at this point?
@derickbailey I obviously don’t need to use `map`, `filter` etc at this point, but I’m invested enough in the library that its easier
— Ben McCormick (@ben336)
It seemed like a possibility to me.
And I rarely use these libraries anymore, so doesn’t that show some evidence?
Well… maybe not.
John-David Dalton – the creator and maintainer of Lodash – steps in to the discussion with this:
Lodash is an active/evolving collection of 300+ modular utils that’ll continue to push beyond ES 5/6/7/.. additions. https://t.co/AvOLZXt5Wg
— John-David Dalton (@jdalton)
YMNK Lodash, by way of the jQuery foundation, has TC39 representation & is involved in the evolution of JS
BERTEIG has updated its Worldmindware page to reflect updates to our training & to highlight instructors & coaches.Scrum and Agile training sessions on WorldMindware.comPlease share!
Nearly three decades ago one of my first bosses pulled me aside – I forget the underlying incident except that I had somehow screwed up – and bluntly told me to “sweat the details.” I clearly remember it to this day, and it became one of the defining pieces of advice I have ever received. It was also a lesson in the power of immediate feedback versus waiting for the annual review.
I began to sweat the details, often obsessively, sometimes too much so. Just ask anyone who has traveled with me. Or lived with me. Learning the value of details, and how to distill, evaluate and discriminate, has helped me tremendously.
Last January I told you how my annual “do something different” goal for this year is to read a work of literature from a different culture each month. Initially this was something of a struggle for someone who typically reads Clancy-esque technothrillers and dry business tomes. Twenty pages, if not more, just to develop a character? You must be kidding! Who has the patience? But I dug in and did it. After all, some of the most valuable goals are the ones that push you outside your comfort zone. It’s been a very rewarding experience.
So far this year I’ve read (just as part of this goal) One Hundred Years of Solitude (Latin America), The Kite Runner (Afghanistan), Things Fall Apart (Africa), One Day in the Life of Ivan Denisovich (Russia), Men in the Sun (Palestine), The God of Small Things (India), Life and Death Are Wearing Me Out (China), and The Wind-Up Bird Chronicle (Japan). I’m currently reading Ceremony (Native American), and next month will be Breath, Eyes, Memory (Haiti). Any suggestions for November and December?
The Kite Runner has easily been my favorite so far, followed by Ivan Denisovich. Ceremony has started out rather slow, but is now becoming an intriguing look at Native American society as well as the experiences of returning war veterans. Life and Death and Wind-Up Bird were interesting immersions into Chinese and Japanese life, although keeping track of the multiple reincarnations in Life and Death (some not as humans!) became a bit difficult.
I’ve realized that what sets these works of literature apart is the depth and detail presented by the authors. Ivan Denisovich really is a couple hundred pages about just one twenty four hour day, but so engaging I couldn’t put it down! In The Kite Runner I truly felt like I was struggling to survive in Afghanistan, dealing with the consequences of war on life, livelihood, and family. This created understanding, empathy, and compassion – exactly what I was looking for when I set this year’s goal.
Depth and details matter when telling a story. Understanding depth and details takes either a talented author, or perhaps a trip to the gemba. That’s one big reason why my wife and I have traveled to over 65 countries – to get the real story. It’s scary how often that real story is at odds with sound bite-driven popular perception.
This is also evident in the lean world. We already know the value of visiting the gemba instead of making assumptions from a distant conference room. Knowledge leaders in the field often ask themselves why lean doesn’t take root at every organization and in a sustainable fashion when there is so much evidence that it works. There’s even a lengthy survey currently circulating among such folks asking that and other similar questions.
I can tell you why: a lack of understanding of the depth and detail of lean. Instead of truly understanding what it’s about, we want to jump to the immediate benefits of 5S or value stream mapping without understanding the “why?” – and then the context of a simple tool within the overarching depth of the total lean methodology and philosophy. It’s why some of us push back on “lean six sigma” because it usually does not overtly include what I believe to be the most important aspect of lean: respect for people. Understanding respect for people, especially the roots from Toyota where it is really “respect for humanity,” is difficult. But without it, lean simply isn’t lean. The true power cannot be realized and sustained.
Lean is not just this or that tool. It is an operating system framework to increase customer value by leveraging the power of people. Understanding the depth and detail, including the historical underpinnings and how it can be uniquely applied to your specific circumstance, is critical for success. Otherwise, even if short-term gains are realized, long-term failure is almost guaranteed.
Similar examples exist elsewhere. Consider all the blog posts on the latest get-rich-quick or weight loss schemes that don’t convey the underlying context and circumstantial variation. How many people assume an author has professional stature just because of a superficially-reasoned argument, perhaps peppered with big words, instead of true studied knowledge and scientifically-evaluated evidence?
Tweets are 140 characters long and television and even some print news these days is reduced to sound bites. The depth and detail has disappeared, and our opinions and decision-making are becoming very superficial – for increasingly complex and global issues.
We are losing the ability to access and process knowledge, lean and otherwise, based on detail and depth. How do we change that?
Perhaps we should start reading literature again to see what we’ve been missing.
- What really matters?
- Of all the things I could do, what is most important?
- Of all the things I could do, what really has to get done this week?
- What do I want to get done this week?
- What am I going to do today?
- Who can help me?
Getting my life under control meant saying 'No' to unimportant stuff so I could say yes to things that matter. Sometimes it even meant saying 'Yes' to unplanned resting, because I am not a machine, and sometimes I need to rest.
How does this work? Here is an example from my life: my kids had kind of gotten used to the fact that their requests never really got processed. I was working so hard on "important stuff" that I never had time for family stuff.
Once I decided doing things for my family really mattered, so I put it on my priorities map as point number one and labeled it with a green dot. Then every week, as I plan my week, I make sure there are a couple of green items in the list of things I want to accomplish this week. The difference was obvious immediately! Now I apply that principle at home and at work.
Here's how this works:
What really matters? These 3, maybe 4 priorities in my life guide what I say yes to. Each priority has a color code for easy identification.
Of all the things I could do, what is most important? I always have too much to do, so I want to focus on things that matter. If I am considering doing something that doesn't match up to something that matters, I ask myself why and whether I should do it!
Of all the things I could do, what really has to get done this week? Some things have a pressing deadline and it's important not to lose sight of them.
What do I want to get done this week? I don't have time or energy to do everything. So of the important things and the urgent things, which ones do I think I can accomplish this week? Unchecked, the urgent tends to push out the merely important, so I sometimes I need to make space for the important. Sometimes that means that urgent stuff gets postponed or even cancelled.
What am I going to do today? This keeps me from going off on a tangent. Sometimes it's even helpful to plan my time in my calendar, for example to make room for a larger chunk of important work.
Who can help me? At the very least, I needed someone to ask me these questions once a week or so, so I remember to answer them! Most approaches to managing your time assume that you are really by yourself. In reality, you can ask a partner, your spouse, an advisor or a professional coach to ask you the questions once a week or so. You can ask other people for help. Individual performance is important, but collaboration enables so much more!
By reflecting occasionally on what you are doing and why, you ensure that you're not just working hard, you're also doing the right thing!
Call for help: I'd like to find out if this approach could be useful in your context. If this has piqued your interest, and regardless of whether you think the answer might be yes or is probably no, I'd like to talk to you! Please contact me, and I'll set up an appointment! Thanks!
UPDATE: I have updated and will continue to update this article to make it clear. First change. The questions changed my life, the information radiators just help me do what I want! Last Update: 12-Sep-2016 at 09:12.
“You have to be run by ideas not by hierarchy,” Steve JobsLearn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Real Agility managers mentor individual staff members to develop expertise, skill and capacity. Real Agility is the merging of Agile, Lean, and Community Development. Find out how managers’ roles change in this short video by Mishkin Berteig.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Real Agility managers help their delivery teams to progress through the stages of team development to reach a sustainable high-performance state. Real Agility is the merging of Agile, Lean, and Community Development. Find out how managers’ roles change in this short video by Mishkin Berteig.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Have you ever needed to do some minor home repairs, and couldn’t find all your tools or all the materials and supplies you needed? Some items were where they belonged and others weren’t?
Or you wanted to cook a meal, and you couldn’t find all the utensils or all the ingredients, because not everything had been put back in its proper place after the last use?
When developing software, have you ever been in a situation where it was hard to find everything you needed? You know there was a list of standard identifiers for county-level taxing authorities somewhere. Was it on SharePoint? The team wiki? A shared network drive? What about this odd-looking branch in the version control system? Is it important, or was it an experiment that can be deleted? Do you have to merge it or can you ignore it? And why hasn’t the network admin assigned to your project returned your calls or emails? You can’t promote your code to the QA environment until you get the appropriate rights granted to the application’s test user id!
Whether you’re puttering around the house, working on your car, cooking a meal, doing the laundry, or writing software, everything is easier when the items you need are at hand and in their proper places.
People working in manufacturing operations learned that lesson long ago. A basic idea in lean manufacturing is 5S; a set of guidelines for keeping a work space orderly, so that people don’t waste a lot of time looking for tools and materials.
Motion is one of the Seven Lean Wastes; it refers to unnecessary motion on the part of workers to walk around or to find tools or parts during a manufacturing process. The analogue for software teams is unnecessary “motion” to look for things in multiple places, whether physical or electronic.The five S’s in 5S stand for five words:
- seiri, often translated as sort, means to dispose of any items that are not necessary to the work to be done.
- seiton, often translated as set in order, means to arrange necessary items so they can be found and used easily whenever they are needed.
- seiso means to clean or to organize the work area, to help maintain order as well as to ensure worker safety. Cleanliness is also treated as an inspection criterion. A clean work area is more likely than a dirty one to be well-organized and usable.
- seiketsu, often translated as standardize, means to create and follow a set of regular procedures to keep the work area orderly and clean.
- shitsuke, often translated as sustain, means to stay on top of things once you’ve gotten everything organized. Don’t let the situation deteriorate again.
Software development differs from manufacturing in a couple of key ways. First, it isn’t a repetitive process to produce copies of the same widget again and again, each one starting from raw materials. It’s a creative activity to produce a unique solution, one-of-a-kind. And yet, software development does involve some repeating patterns of work.
Secondly, a software development team has “work spaces” in both the physical and the virtual realms. Manufacturing operations don’t have virtual spaces. 5S originally came about as a way to organize cells in a lean manufacturing setup, so that workers wouldn’t spend 40% or more of their time walking five steps this way and five steps that way every time they needed to use a particular tool.
The repeating patterns of work, and the fact we often need access to common information, shared software artifacts, tools, and environments, mean that 5S lends itself very nicely to software development work. And it turns out to be easy to apply 5S to virtual spaces as well as physical ones.Physical Work Space
Whether in a team room or in individual work spaces, we can save ourselves a lot of time and frustration by making sure the things we use frequently are easy to find. Some examples:
- List of phone numbers
- List of chargeback codes
- Batteries for wireless mice and keyboards
- Remote control for the overhead projector
- Keys to the supply cabinet
- Supplies for process visualization (sticky notes, etc.)
- Whiteboard markers and erasers
- Cables, chargers, and similar items
You get the idea.Virtual Work Space
Software teams can also apply 5S to their virtual work spaces and virtual tools, such as:
- Version control system (delete temporary branches that aren’t needed)
- Source code (remediate technical debt)
- Test code (remove meaningless tests; organize test cases by functional area, not by test subject)
- Build scripts / configuration files (delete unused configuration settings and steps)
- Deployment scripts (delete unused steps)
- Environment provisioning scripts (delete unused steps, replace obsolete versions)
- Servers (clear out unused directories, defragment disks)
- Documentation (delete or update obsolete information; keep information organized logically; add indexing feature, if missing)
- Backlog (no need to keep “dead” backlog items forever)
- Development environments (clear out unused directories, uninstall unused software)
- Test environments (ensure test environments are identical to production environments)
- Staging environments (ensure staging environments are identical to production environments)
- Reports / statistics / metrics (remove obsolete or unused data from reports and logs)
- Backups (keep backups in sync with current configuration; test restore procedures regularly)
- Recovery (test recovery procedures regularly)
One of the simplest and most impactful things you can do is to establish and adhere to consistent naming conventions. This is not included in the list above because it applies to every item in the list. Consistent names make it easier for people to locate information and artifacts they need, easier to identify the purpose of any given artifact, and easier for people to know what to name new things they create. As a result, it also facilitates automation of any and all repetitive tasks, whether it’s automated testing, automated deployment, automated monitoring of production environments, creating reusable templates or boilerplate code, or anything else you can think of to automate.
Real Agility managers facilitate effective meetings and workshops with their staff. Real Agility is the merging of Agile, Lean, and Community Development. Find out how managers’ roles change in this short video by Mishkin Berteig.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!